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FORMS CREATION METHOD AIW E<:OMMERCE m 



BACKGROUND OF THE INVENTIGN 



1. Field of tibe Ihyeation 
The present invention relates generally to forms creation software and e- 

commerce, and more particularly, to a method, system and software for creating and 
maintaining highly scalable and fully functional, multi-step web-based forms and the 
creation of a multi-tiered e-commerce method and system* 

2. Descriptioii of the Relaied Art 

There is a specific- problem with current forms development software in that they 
are not scalable, and are not easily implemented across different computer systems. Such 
prior art systems typically require experienced programmers to design the forms on those 
systems. 

There is also the problem of controlling the workflow in e-commerce operations, 
particularly those e-commerce q)eradons using multiple components. 
These problems have not been solved in the prior art. 

SUMMARY OF TEDE INVENTION 

Briefly, in a fir^t a^ect the present invention comprises an integrated development 
method for creating forms, including the steps of: storing at least one schema for a form 
in a first file at a computing resource,, wherem* the schema comprises minimal user 
20 interface representations; accessing at least one template of a form in at least one second 
file s^arate from the first file at a c(»nputing rescnirce, wherein each of the templates 
comprises a user interface rq)resetitation of the form; selecting one of the at least one 
template and one of the at least one schema; and creating at least one linking file that 
links the selected schema and die selected template* ' 
25 In a further aspect of the invention, a method is provided to publish forms 

comprising the steps of: creating a schema; providing a list of predefined templates; 
selecting a template; selecting a publishing destination; and linking the schema to the 
selected template* 
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In yet a further aspect of the present invention, a method is provided for creating a 
regular expression file comprising the steps of: inputting and presenting a name for a 
regular expressicra; inputting and presenting a pattern for a regular expression that is to 
be used in a vaiidaticMi engine; inputtmg and presenting an error message for user inputs 
5 that do not match the pattern; inputting at least mc lest case; and comparing the test case 
to the pattern; and presenting a message in response to the c(Hnparison step. 

In a further aspect of fte present invention, a. navigation engine program product 
is provided^ comprising: a computer usable medium having computer readable program 
code embodied therein comprising: first code for transfonnmg data--centric hierarchical 
10 storage and retrieval mechanism data to presentation language; second code for receiving 
data in presentation language and converting the received data to the data-centric 
hierarchical storage and retrieval mechanism; third code for performing attribute based 
validation on tiie data; fourth code for providing navigation among present pages; and 
fifth code for saving the data in reqxnise to a command. 
IS In yet a further aspect of the present invention, a method for processing forms cm 

a user-interface program is provided, compridng the steps of: receiving an engine and a 
file with a form including a schema and a template m a data-centric hierardiical storage 
and. retrieval mechanism; transformmg with die engine the form from the data-centric 
hierarchical storage and retrieval mechanism into presentation language and presenting 
the form at the user-interfoce program; receiving user input data in the presentation 
language; converting the user input data to the data-centric hierarchical storage and 
retrieval mechanism; performing attribute based validation on the converted user input 
data; incorporating any error detected in the validation step in the data-centric 
hierarchical storage and retrieval mechanism into the form schema or separate form 
schema; converting the any error into presentation language and presenting an error 
message associated therewith to the user; allowing the user to correct the user input data, 
if necessary; and saving the user input data. 

In a yet further aspect of the presat invention, a runtime environment method for 
an electronic forms applications is provided, comprisuig the steps of: receiving a forms 
request froni a user-inter&ce program; determining if the user-interfiace program is 
compatible or not compatible with a data-centric hierarchical storage and retrieval 
mechanism; sending from a computing resource to the user-interfece program, if the 
user-interface program is compatible with die language, a schema file contammg form 
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informatioD to be inserted into a form template and a form navigation engine and a form 
input validation engine; if the user-interface program is not. compatible widi the storage 
and. retrieval mechanism, sending user input information to the computing resource for 
processing and sending a presentation language version of form pages resulting from the 
5 computing resource processing back to the user*interface program. 

. In a yet further aspect of die present invention, a method for creating a form file 
is provided Comprising the steps of: ^ring in a form file a path to a schema in a first 
file at a storage location; storing in the form file a path to a template in a second file 
different from the first file at a storage location; and storing the form file at a user 
10 location. 

In a yet further aspect of the present invention^ ^ method, for performing 
customized actioiis in a computing environment is provided, comprising the steps of: 
providing at least one selector file, each selector file containing at least one selector 
pattern and associated with an action set that contains at least one action, wherein the at 
IS least one action contains at least an eAgent ID and an associated action document ID; 
obtaining a document for processing from a queue; searching the document for a. match to 
at least one of the selector patterns of the selector files; if a match is found for <me of the 
selector patterns, executing the at least one action in- the Actionset associated with the 
matched selector file, including loading an eAgent specified by the eAgent ID; and the 
20 eAgent reading an action document specified by said associated action document ID and 
performing an action specified tiierein. 

In yet a further aspect of the present invention, a system for generating forms in a 
computing environment is provide, comprising: a schema database; a template database 
sq>arate from the schema database; at least one linkage file, each containing code to link 
25 a selected schema with a selected template; a database of validation patterns sq>antte from 
the schema database and the template database; and a database of query information 
separate fix>m the schema database and die template database. 

In yet a further aspect of the present invention, a system for performing actions on 
docmnents in a computing environment is provided, comprising: a selector file database 
30 containing a plurality of selector files; an Actionset database containing a plurality of 
Actionsets, wherein each selector file is associated with exactiy one Actionset; an eAgent 
q)ecific action document database containing a plurality of action documents that are 
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specific to eAgeats; wherein eadi Acdonset in the Actionset database is associated with at 
least one action document. 

In yet a further aspect of the present inv^tion, a cc»nputer program product for 
an integrated dsvclopment environinent is pnnided, comprising: a computer usable 
S medium having a compute readable code embo^ed Aerein, including: presentation host 
code, die presentation hpst code inchiding shared user interface and lo^ code 
components! code for reading a IDE configuradon« and code for loading any IDE 
component code and business logic components code as defined in the IDE configuration; 
at least one IDE component code loaded by the presentatiw host on the user-mterfiBCe 
10 program, the IDE component code including a user interface; at least one business logic 
component co^ lo^ided by the presentation host on die user*inter£ace program, the 
business logic component code defining the intenelatioaships between objects rq>Fesented 
in the user interface. 

In a yet further aspect of the present invention, an integrated development 
IS environment method is provided, comprismg the st^s of: loading onto a computer 
resource code iti a deied architecture comprising: a presentation host tier that inchidcs 
presentation host code, the presentation host code includmg shared user mter&ce and 
logic code components, code for reading an IDE coniigaration, and code for loading any 
IDE component code and business io^c conqion^ts code as ilefined in the IDE 

20 configuration; an IDE component tier, including at least one IDE component code loaded 
by the presentation host on the user-mter£ace program, the IDE component code 
includmg a user interfece; a business logic componem tier, including at least one busmess 
logic component code loaded by the presentation host on the user*interface program, the 
busmess lo^c componmt code defining die interrelationships between objects represented 

25 in the user interface; a data access abstraction layer tier, including a data access 
abstraction layer code that allows business components code to read and write information 
to/from a computing resource; and communicating with a remote computmg resource 
throu^ use of die data ^access abstraction layer code. 

In a yet further aspect of the present inventim, a computer program procbct is 

30 provided comprising: a medium with machine-readable code stored thereon which gives 
the ability to its computer to perform form creation tasks, including: first code for 
facilitating a schema database; second code for facilitating a template database s^arate 
from the schema database; third code for facilitating at least one linkage file, each 
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containing code to link a selected schema from the schema database with a selected 
template from the template database; fourth code for facilitating a database of validation 
patterns s^arate from the schema database and the template database; and fifth code for 
facilitating a database of query information separate from tbt schema database and the 
template database* 

BRIEF DESCRIPTION.OF THE DRAWINGS 

Fig. 1 is a schematic block diagram diowing the system architechire for the forms 
creation system and method of the present invention. 

Fig. 2 is a static block diagram of the overall invention architecture, including die 
forms creation system and method in combination with the e-commerce system. 

Fig. 3 is a process workflow blodc diagram for a client-side processing software 

deagn. 

Fig. 4 is a workflow block diagram for a server-side processing software design. 
Fig. 5 is a process workflow block diagram of a forms publishing software 
process. 

Fig. 6 is a static block diagram of an eAgent architecture. 

Fig. 7 is a process workflow block diagram for the eAgent architecture software. 

Fig. 8 is a static block diagram of an integrated development system for an e* 
commerce architecture. 

Fig. 9 is a schematic diagram of a forms schema. 

Fig. 10 is a schematic diagram of a regular expressions schema. 

Fig. 11 is a schematic diagram of a query schema. 

Fig. 12 is a schematic diagram of a templates schema. 

Fig. 13 is a schemadc diagram of a template, schema. 

Fig. 14 is a schematic diagrwi of a publishing folder schema. 

Fig. IS is a schematic diagram of an mtegrated development environment schema. 

Fig. 16 is a schematic diagram of an XML selector schema. 

Fig. 17 is a schematic diagram of an Actionset schema^ 

Fig. 18 is a schematic diagram of an action query eAgent schema. 

Fig. 19 is a schematic diagram of a queue conflg schema. 

Fig. 20 is a schematic block diagram of a system for performing actions on 
documents. 
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Fig. 21 is a schematic diagram illustrating the publishing wizard-Publish.ASP 
interaction between the IDE and the server. 

DETAILED DESCRIPTION OP THE PREFERRED EMBODIMENT 

The present invention, in a preferred embodiment, may incorporate technologies, 
5 including: 

• Extensible Markup Language PCML), both as an object store and as a data 
store for flexibility, extensibility and easy mtegradon with odier systems. 

• . Extensible Stylesheet Language (XSL) and JavaScript, using the XML 

DOM as the transformadon engine, for transforming the meta data of a 
10 form mto an HTML form and for transformmg one XML implementation 

into another. 

• Cascading S^le Sheets (CSS), for manipulating the di^lay of the XML 
Data. 

• Dynamic HTML, for making use of client-side processing and updating 
15 page information without needing a roundtrip to die server. 

• Regular Expressions, to enable validation and transformations of entered, 
data. 

• Active Server Pages (ASP) for support of a multiple browser environment. 

• COM components, for packaging complex segments of the process into 
20 more modular and scalable sections. 

• JavaScript, for validation and client-side navigation logic, as well as sever- 
side ASP code. 

• Microsoft Transaction Server (MTS), for supporting a large number of 
concurretit users. 

25 • A queue-based approach (using the file system or a message queue 

server), for maximum scalability, reliability, response time as well as 
integration with other systems. 

• A template-based ^roach, where template designers can design the 
templates that "plug in" to the present inventicm, thus providing a highly 

30 customizable look and feel, as well as separation and ^)ecialization of 

tasks. 
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• An ActiveX based integrated development environment (IDE), for 
jnanipulation of XML files over the Internet using HTTP and the ability 
to associate the present invention with a template over the web - all using 
a graphical user inter&ce (GUI). This obviates the need for the forms 
5 designer to learn any of the above technologies to create and maintain the 

present invention. 

It should be noted that aldiough die preferred embodiment is described in the 
context of current language types such as XML, HTML, CSS, and die other listed 
languages and conventions for ease of reader understanding, it is not intended to limit the 
10 invention to these languages and convmtions. For example, die references to XML can 
be rq>laced by any data-centric hierarchical storage and retrieval mechanism; and HTML 
can be replaced by any apprq>riate presentation language. 

A number of terms diat are used through(Hit the ^)ecification are defined below. 

Data-ceatric Hierarchical storage and retrieval medianism 
15 A data-centric hierarchical storage and retrieval medmnism comprises the ability 

to store and retrieve hieraitfaically organized data. It includes both the format in which 
the data gets stored, as well as how to access the hierarchically organized data. 

Action Documoit 

A document that defines parameters for an action in the data-centric hierarchical 
20 storage and retrieval mechanism. 
Routing Document 

A routing document contains a document and tracks actions executed on the 
document by the eAgents. 
Action 

25 An action can contain one or more processes that may or may not be exeoited by 

aneAgent 

eAgent 

An eAgent is a software compcment that performs the action on the routing 
document and on the associated action document. 
30 Queue. 

A queue can be a folder, mailbox, queue server or any computing resource 
capable of queuing <kita. 

Code for facilitating a database 
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Cpcfe for &ciHtadog a database encompasses the ability to set up, manipulate 
and/or maintain a database. 
Schema or Metadata 

Metadata or sdiema are data diat describe the aspects of a fomi that change from 
S form to foxm, excluding exact (graphical) presentation. Examines will be provided 
below. The terms "schema** and "metadata* are used interchangeably in diis qTplication. 
System Requirements 

The user of die present invendon who wants to fill out a form only requires a 
browser capable of HTML 3.2 or other presentation language and basic CSS support, 
10 e.g, Internet E3q)lorer 4.0 or above, Netscape Conununicator 4.0 or above. 

The folbwing table lists the requirem^ts for the forms designer and the server on 
which the jpresent inventidn are used.at the present time: 



Description 


Forms Designer 


Server 


Operating System 


Windows 9S, Windows 98, 
Windows hTT 4.0 
(worlcstadon or server) or 
Windows 2000 (workstation 
or s^i^r) 


Windows NT 4.0 Server wth 
service pack 4 (or above) and 
Cation Pack (IIS 4 and MTS), 
or Windows 2000 Server 


Additional Software 


Internet E}q>lorer S 


Internet Explorer 5 


Minimum RAM- 


32MB 


128 MB 


Hard drive space 
available 


10 MB 


5MB 



Referring now to Fig. 1 there is shown a block diagram of the forms creation 
IS system of the present invendcm. The individual components shown in this figure will be 
described, followed by a description of how these components are controlled using 
flowcl^arts of the software of the present invention. The specific XML vocabularies used 
will be covered in a later section, that will include a tree diagram, explanation and 
samples. 
20 Schema library 

An important aspect of the present invention is the use of Meta data or schema. 
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As noted above» Metadata or schema are data that de^ribe the aspects of a fonn 
that change from form to form, excluding the exact (graphicd) preseniadon. Examples 
include but are not limited to . 

> Name and caption of a field 

5 > Help text 

> What control type to use 

> Whether the field is required and any odier validation rule 

> Whether to provide the user of the form with a lookup list» and the entries of the lisL 

Hie following are examples of what would not constitute Meta data or be part of 
10 tte schema. 

> Color (badcgroond, font» etc.) 

> Fonts (type, size, bold, italic, ...) 
' > Positioning 

> Gn9)hical elements, including lines, circles, logos, etc. 

15 > HTMLtags for di^Iay of input controls, e.g. <I>n?UT>,eto. 

Using this approach allows the separation oif content from display, and the 
possibility to diange each one completely independently of the other* 

The schema of a form is represented are ^ically represented in a specific XML 
or other data-centric hierarchical vocabulary, that includes those elements and attributes 
20 needed to describe a form, but not its di^lay unplementation. 

An extremely simplified example would look like this: 

<form names:' "Registration" > 

<fidd name=*FirstName" required»"true"/> 

<fieldname=*'LastName" required«'*true'*/> 
25 . <ficldname-**eMaiI* rcquired«'*true"/> 
</fonn> 

Hie schema would be created by a forms designer and stored in a schema library 
10. The schema library 10 provides the forms designer with die ability to reuse 
individual sections or fields or the endre schema in other forms« Any storage 
30 configuradon may be utilized including remote and/or distributed storage accessible over 
a network, over the Internet, or in any other convenient fashion* 
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Query Ubraiy 

In one aspect of the inventicm^ in ord^ to present the forms designer with a list of 
valid entries to peculate form fields, die present invention provides die ability to gather 
die data for list/lookup from any ODBC/OLE DB compliant database, mcluding SQL 
S Server, Access, Oracle, DB 2, DBase, Informix, Sybase, Microsoft Exchange and odiers. 

Instead of including the necessary information for executing a query dkecdy into 
the native schema of a form, the present invention uses a query library 12 to store queries 
and only references them inside die native schema of the forms by the given name of die 
query. Hiis results in die ability to have a central repository 12 of all database-related 
10 queries for ease in making changes and flexibility. Queries can be changed independently 
of the forms that are using them, and any saved changes take immediate effect. 

The queries themselves are defined using a specific XML vocabulary, and the 
connection information to the databases, in a preferred embodiment, is kept in Microsoft 
Data Link Hies (udl files). 
15 Note diat to fecilitate the use of die query library to facilitate a central change to a 

query that is used in a plurality of different schmia, die present invention, in a preferred 
embodiment, stores the schema in the schema library 10 in both a native sdiema format 
and a compiled format In the native schema format, the schema includes one or more 
links to the query library at those sections of the form fields and sections that are to 
20 incorporate a particular query therein. The compiled schema format is also stored and 
incorporates die query itself, rather than a link to the query* 

Updating a given schema with dianges inade to one or more queries would 
typically be accomplished sinq>Iy by recompiling the schema. Alternatively, the updating 
can also be programmed to be accomplished at runtime. 
25 VaUdatfon Library 

A validation library of regular e3q>ression5 14 . is provided that contains a list of 
regular expressions. 'Regular expressions* is a pattern matching technology, that allows 
for the comparison of an input string against a pattern (regular expression), and that 
evaluates whether die pattern is found m the input string. In this way, a variety of 
30 validations can be executed when a user inputs data into an electronic form, mchiding 
checking for valid email, zip, state, phone, SSN, etc. Each regular expressicHi is given a 
user-friendly name and is called from die schema library 14 by the forms de^gner usmg 
diat name. The regular expressions library 14 may convenientiy store the regular 
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expressions in XML or other convenient data^ntric hierarchical storage and retrieval 
mechanism. 

The same approach may be used as was used for the query library. The native 
schema stored at in the schema library 10 may include one or more links to regular 
S expressions stored in the regular expressicms library 14. The compiled schema stored in 
the schema library 10 would include the particular regular expression without the link to 
the regular expression library 14. Accordingly, regular- expressions can be updated by 
one centra] phange to the regular expression library 14». which change can be propagated 
dirough all of the sdiinna m the schema library 10 using that regular expression simply 
10 by recompiling the particular schema. 
Templates* 

A Template is a collection of files, that may include ASP, CSS, images and other 
convenient items, whidi define the layout of the page in which die forms using that 
template are rendered. The layout i^ically includes the company logo and a navigation 
IS bar to allow the user to navigate to other pages of the $ite, plus the look and feel of the 
page, including colors, fonts, positioning, and other aspects. 

The present invention enables leveragmg the full power of ASP/HTML/CSS to 
format the page most ways that the forms derigner may wish to display the form. The 
template files can be designed with any tool that can create ASP/HTML/CSS, including 
20 Front Page, Visual InterDev, Dream Weaver or even a simple text editor. The templates 
that are created are stored in a template library 16. 

To make an ASP page a template, a designer simply needs to enter appropriate 
lines of code into his/her ASP page (done automatically when the form is published to the 
Web) and create additional descripticms, in associated XML files. 
25 The present invention allows the forms designer to easily select a template from 

the template database 16 with which to associate a schema. 

Display and Navigation £a£^e 

Tasks 

Also included in the system is a display and navigation engme tiiat performs the 
30 following tasks 

> Transforms the XML forms into HTML forms. (-> Forms translator) 

> Takes the input into HTML forms and transfers die data back into XML 
forms. (-> Forms extractor) 
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> Performs validatioa logic that only allows submission of valid data and notifies 
users of errors and what needs to be corrected. 

> Diq)Iays a preview page for user verification of entries. 

> Page navigatiott to allow moving forward and backward, including ensuring 
5 that any entered data are saved (i.e, , NEXT, PREVIOUS, SUBMIT), 

> Saves the submitted form data and relevant schema into a queue (the preferred 
implementation uses file system as a queue}* 

In cx-der to accomplish the foregoing tasks several components are used. What 
(hey are and bow they are used is described in the following sections. 
10 CUent-Side vs. Sorer-Sde processfaig 

In a preferred embodiment, tiiere are two versions of the display and navigation 
engine 18. For clients that use Internet Explorer 5 (IE 5) or other browsers that are 
compatible with a data<entric hierarchical storage and retrieval mechanism, a substantial 
portion of the processing may take place on die client-side (browser). For other dients 
IS that axe not compatible with a data-centric hierarchical storage and retrieval mechanism, 
all the processing occurs cm - the server. Both versions share some components / 
compox^t logic, while some parts are specific to each version. 

This preferred embodiment using two types of display and navigation engines is 
utilized in order to support a substantial number of browsers. Note that the display and 
20 navigation engine for IE S and other similar type browsers use the client-side 
funcdonality to offload processing to the client and thereby obtain improved performance 
(no server round trips) and higher scalability (less server processing needed). 

At the present time Internet Explorer 5 comes with sufficient support for the XML 
DOM (Data Object Model), XML data^ islands, XSL and DWTML (Dynamic HTML), 
25 which are used .to implement a client-side version of the present invention. . Future 
browsers that support diese or comparable technologies will also support client-side 
processing. 

Fonns Translator 

Current te-owsers have no standard way of displaying any XML or odier data- 
30 centric hierarchical elements in a meaningful way. The present invention uses a forms 
translator in &e display and navigation engine 18 to transform the XML forms into 
HTML forms. 
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The forms translator, in the present design, is implemented primarily as XSL style 
sheets. The Extensible Stylesheet Language (XSL) allows the transformation of XML 
into another form of XML, HTML or any other text based format. 

The forms translator maps in a standard fashion the relevant XML elements and 
5 attributes to HTML elements and attributes, and supports multiple controls, field level 
help, error messages; 

Fonns Extractor 

Once the data has been entered into the HTML fonn by a user, the data must be 
extracted again into XML by the display and navigation, engine 18. The mechanisni used 
* 10 to accomplish this is a nammg convention. The format for tbis convention is as follows: 
flcL<contioltypc>_<secttonname>_.<fieldname^^ 

^ere: ■ 

is the delimiter that separates the parts to be parsed 
**M* is dieprefixT^ikihmdicatestiuitafbzmvanableis^^ 

15 <cc»itroltype> is a descriptive (not necessarily drectJy listed in the XML DOM structure, for 
example "selectmuhi'' mi^t requite a match of controltype attribute=*se}ect:^ and multiplsdect 
* attnljute^'ycs') term used to uriquely identify a ccmtcol^pe m A control type is 

arefocnce to the XML representation ofan PTIMLdispI^type^suchas text box or select lliis 
approadi aUo^ tfie fornis desigper to define custom controls, suc^ 

20 constitutes a composition of several simple controls* 

<sectionname> and <fieldname> are the name identifiers of the section/field. 

The server-side version uses the ASP Request object to retrieve the mformation 
entered, and using die naming convention above transfers the information into XML. 
The cUent-side version uses DHTML, in the preferred embodiment 
25 The conversion to the data-centric hierarchical storage and retrieval mechanism 

may occur almost simultaneously with the data entry, or may occur periodically, or may 
convenientiy occur when die user clicks NEXT* 
Validatioii 

Most typical validation in die. prior art acts directly on the user interfiace. This 
30 approach tightiy couples the validaticm to the di^Iay mechanism and offers litde 
flexibility. 

The present inventive approach allows die validation to work no matter what user 
interface has been chosen. This is accomplished via the display and navigation engine 18 
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by first converting the information from tbe display to the XML or other data-centric 
hierarchical storage and retrieval mechanism, and only dim performmg die validation on 
tbe XML converted data. 

By using this 24>proadi, the same source code (or the same logic) can be used by 
5 both, the client and the server-side version of tbe validadcm software, and tbe present 
invention is able to support changes m tbe user interface without having to change the 
validation logic. 

The validation logic hi the display and navigation engine 18 itself also does not 
communicate directly witii the user inter&oe once errors have been found. Instead it 
10 flags the erroneous field/section by including an error message inside the XMI^^onverted 
data. This offers the advantage of being able to customize bow the error message is 
displayed to tiie end user. 

The validation component functions to dieck every field for all validation rules 
defined and st<q>s processing that field/section once/if the first error has been found. 
15 Another key part about the validation is tbe ability to use attribute-based 

validation. Examples of attribute-based validation are ""required," ''nmlength,*' 
''minlength,** "minvalue/ ^maxvahie,'' and "pattern.*" All that the forms designer needs 
to do is speciiy a value for that attribute, and the validation component will ensure that 
the validation is performed accordingly, and tbe display engine will en^mre the error is 
20 communicated to the end user. 

By using this approach, non-programmer forms designers can perform 95% or 
more of die typical validation on most of the forms witiiout having to do any 
programming. 

Preview Page 

25 Tbe preview page for the di^lay and navigation engine 18 is simply a read only 

view of the caption and values of die fields entered by tiie end user. Tbe current 
implementation of the innovation uses an XSL s^le sheet for the display. 
P^ Navigation 

Page navigation on the client is handled by local Jscript in a preferred embodiment 
30 in order to implement flie NEXT, PREVIOUS, AND SUBMIT commands. 

Note tiiat the server-side version of die display and navigation engine 18 (for 
nonXML compatible browsers) needs to keep track of the current section being displayed 
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to Ac user. This is acxomplished by passing a section number as a bidden textbox for 
every di^lay. 

Maintaining state 

The data entered by the end user is transferred mto the XML document that 
S contains the schema. For the client-side version of the present invention, there is no 
other problem associateid with maintaining state* 

For the server-side, version of the invention, additional code has to be added, 
because HTTP is a connection-less protocol. The solutira used by the present invention 
is to store the XML converted data as a file widi a unique identifier on the server, and to 
10 pass this unique identifier in a hidden textbox from page to page. In this way any 
previously .mtered data is available when navigating among pages. 
Submission 

The typical action in prior art designs when an end user is submitting form data 
(which generally will occur when the end user clicks SUBMIT) is to direcdy and 
IS synchronously act on the data* e.g., write to the database, send emails, etc. This 
approach results in the end User being required to wait until all fltese actions are 
completed, and in case of the database being offline, the user losing alt of his/her data. 

The present invention instead uses a queue-based approach, where all data entered 
and relevant schema are simply written to a queue, and an acknowledgement is sent to the 
20 user for his/her submission. 

The queue mechanism has several advantagefs: 

• Quicker site response time. The user does not need to wait until the 
actions based on his input are performed. 

• Queues don't lose data even if the cotmectu>n between the Business 
25 TlvServer and the Database Server is down. Messages will contmue to 

be queued in the queue, and processing will continue as soon as the 
connection is, restored. 

• Forms a log file of transactions. Allows for every insert request to be 
logged. 

30 • Independent dianges— the processing performed on the submitted data 

can be changed completely mdependently from the forms themselves, as 
long as the structure of die form message remains the same. 
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It should be noted diat in the preferred embodiment, the client-side version (i.e., 
compatible with XML or odier data-centric hierarchical storage and retrieval medianism) 
submits its data usmg the XMLHTTPRequest class from Microsoft's XML parser to send 
the XML to the web server. This again reduces die processing the server needs to 
5 perform^ because the transferring of the end user-entered data in the HTML form to 
XML has already been performed by die client browser. 

Use Of XMtr in Ibe present invaition ?1.0 Programmatic Creation / Reading 
ofXMLfDes 

The present inventicm provides GUI tools to edit XML files. The XML files 
10 themselves are never directly exposed to the forms designer. Using this q^roach ensures 
the consistent, error-free creation of the relevant XML files and facilitates use by the 
forms designer. 

All of die tools that are needed to create the XML files are embedded into an IDE 
for easy access and consistent use. 
15 Server- and Client* side Fiowdiarts 

The following figures are intended id clarlify the processes that are occurring 
within die server-side and dient-side implementations of the present invention, while 
highlighting die differences. The differences are primarily due to how the memory and 
instruction control and execution is partitioned differently between the different 
20 in:q)lementations* Bodi have functionality required of die server and client but differ in 
where tbe primary processing occurs. 

Flaw pescr^vdons - Process Workflow of cllmt-side processing 
Referring now to Fig. 3, there is shown a schematic flow diagram of the present 
invention for the dient-side impl^entaticMi (XML or data-centric hierarchical storage 
25 and retrieval medianism compatible browsers}* 

> Server receives ASP or otfier standard page request. 

It should be noted that instead of ASP, which is the preferred embodiment, any 
senrer-side SCTipting/programming solution, such as JSP, could be used. 

> Step A; 

30 The server-side software processes tbe request at runtime. This encompasses: 

> Loading the schema. 

> Optional- initializing the schema (on tbe fly modification) by a custom ASP 
script, i.e. adding a field at runtime. 
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> Preprocessing the schema for any database lookups. 

> Optional initializing values by a custom ASP script, i.e. p(>pulating a fonn 
with vahies at runtime. . 

> Putting out the resulting schema as an XML island as part of the HTML page 
5 that is sent to the client 

> Sending the full HTML page with the XML island down to the browser. 
> Stq)B: 

After the HTML page and all associated files (XML, XSL, CSS. JavaScript, images) 
have,been loaded, set the first page to be die active page and call step C to display it. 
10 > StepC: 

The client-side runtime software calls XSL style sheets to the schema file to display 
the acdve page of the form. It is here where the schema of the form is converted to 
HTML. The conversion includes form/page/section headers and help text, as well as 
informadon regarding input fields. This^ includes captions, different HTML controls 
15 to capture input for them, required icons, error messages in case there have been any 
errors, etc. 

The transformation/conversion usps dynamic HTML to chiange the content of the page 
after it has been loaded or after an end user has navigated to a new page by clicking 
NEXT or preview. There is no need to roundtrip to the server. 
20 > StepD: 

Here the user enters his/her data and clicks on navigation controls to move 
forward/backward. The client*side display and navigation software awaits the 
activation of a navigation control. 

> StepE: 

25 Having activated a navigation control, the client-side runtime software transfers the 
entered data of the page into the schema, which resides as an XML island inside of 
tiie HTML page. 

> SthpF: 

In this step, validation is executed for all sections/fields of this transferred page. Hie 
30 outcome of the validation is documented inside the schema. 

> Steps Fl and I^-Page calculation: (Errors?/Last Page?) 

> If an error has been found, then step Fl causes die same page to be displayed 
again (step C). 
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> Otherwise in step F2 It is checked whetto- it is the last page- If it is the last page, 
then a preview page is shown. (stq) 0 

Note that the preview is optional* If the preview is disabled for this form instance then 
the data gets sutenitted after the last page has been filled and the sulmiit button 
5 activated. 

> If there is neither an error nor the last page, the active page is being set as requested, 
i.e. the next or previous one and then dsplayed (step Q 

> StepG: 

10 Using a style sheet for preview, the mformation entered in the schema is transfonned 
to an HTML preview page and displayed, 

> StepH: 

After having clicked NEXT/SUBMIT on the preview page, the XML schema is 
, transformed into anodier XML document using an XSL style sheet for this purpose. 

IS • This allows, for example, redtpdng die size by only including needed information, 
digitally signing the documrat or transforming into any other desired format The 
transformed XML is sent to the server. This procedure of scaling down the aze of 
the document (deleting items such as display-related attributes, such as the control 
type to use, the width of the control, and validation^related attributes, such as the 

20 isvalid flag and the errormessage attribute) is used to conserve bandwidth. 

> Step I: 

The XML is received on the server and submitted to a message queue (e«g., the iBIe 
system or MSMQ)» Optional post-processing is executed. Then, an 
acknowledgement is sent back to the browser. Optionaify, a recGrecdon to the next 
25 form, home page or other page is done* 

Flow Descriptioiis - Process Workflow of sarver-side processing 
Referring now to Fig, 4, there is shown a schematic diagram of die execution flow 
for server^side processing that will be implemrated if the browser is not compatible with 
a data-centric hierarchical storage and retrieval mechanism sudi as XML. 
30 > In the initial step the server receives a request from an end user browser. 
> Step A: 

The runtime software loads and preprocesses the schema designated in the end user 
request file. 

The loading and preprocessing may be in a preferred embodiment, identical to the 
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client-side version, including the optional initialization of the schema or initialization 
of the values by a custom ASP script^ with the following exception: 
The schema gets saved to a temporary folder on the server. 
The active page is set U) be the first page. 
5 > StepB: 

- The runtime software ^plies multiple XSL style sheets in the welMcnown manner to 
convert/transform the first page of the schema from XML to HTML. The 
transformation includes form/page/section headers and help text, as well as 
information regarding input fields. This includes captions, different HTML controls 
10 to capture input, required iccms, error messages in case there have been any errors, 
etc. Also inducted are two hidden textboxes that contain the globally unique ID 
assigned to this form instance and the active page number. .As noted earlier, this 
unique ID allows the server to keq> track of which client called. 
. > StepC: 

15 The server sends die resulting HTML to the. browser, 

> St^D: 

The browser displays die page. Note: there is minimal or no runtime software on the 
client, i.e. no JavaScript, no XML nor XSL. 

> StepE: 

20 The user may now fill in the values for the fields and use the navigation jnittons. 

> Step F: 

Upon activating a navigation button, all of tfie field values inputted by the end user 
plus the values from the hidden textbox (globally unique ID and active page number) 
are sent to the server; as well as which navigation cQntrol was chosen by the user. 
25 > StepG: 

The runtime software on the senrer extracts the unique ID from the received data and 
loads the saved schema. 

> StepH: 

The server runtime software then transfers page values to the designated schema using 
30 the ASP Request object to read the incoming data and- the XML DOM to write to die 
schema. 

> Step I: 

The server runtime software then validates the received page values against all 
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validation rules and updates the schema with any error information. The schema is 

then saved again on the server using a unique ID. 

Steps II and 12-Page calculation: (Enon? / Last Page?) 

If errors occurred, then step II causes the same page to be di^layed again (with the 

error messages). 

Otherwise, if it is the last page> then step 12 causes the preview to be shown (Step J). 
If it is not the last page, dien step J2 causes the execution lo update the active page 
number and di^lays that page (Step B). 

Note that the preview is optional. If the preview is disabled for this form instance then 
the data gets submitted after the last page has been filled and the submit button 
activated. 

> Step J: 

The server runtime software then uses XSL style sheet to transform sdiema (with 
data) into KTMh for the preview page, as well as adding hidden tmboxes for 
globally unique ID and active pa^ number. 

> StepK: 

The server then sends the transformed HTML to the browser. 

> StepL: 

Browser displays preview page, 

> StepM: 

The user then clicks PREVIOUS or NEJCT/SUBMIT, If the user clicked 
NEXT/SUBMIT, then the browser sends to the server the globally unique ID and 
active page number in step M. 

> If die user did not click NEXT/SUBMIT, then the last data enury page is ^own again 
(stepB). Otherwise it goes to final proccs^g (stq> N)* 

> StepN: 

The nmtime softuw at the server dien toads the saved schema usin^ 
unique ID. The XML sdieroa is transformed into anotiier (typically) reduced-size 
XML document using an XSL style sheet for this purpose. As noted previously, diis 
conversion reduces the size of the document by only including needed information,, 
digitally signing the document or transforming into any other desired format The 
resulting schema is saved to the message queue. Optionally a post-processing script is 
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executed. The nmtiine software then sends an acknowledgement and/or next 
fonn/page to the browser. 

Process Workflow of eAgent Architectiire 

Referring to Fig. 6, there is shown the basic system configuratim for the eAgent 
tiered processing architecmre of the present invention. It should be noted that this system 
architecture may used indqiendendy of .the forms creation and completion processing 
discussed earlier. Referring to the figure, one or more message queues 26 conununicaies 
with a qurae abstraction layer 40. The queue abstraction layer 40 communicates with a 
queue manager 42, which, in turn, communicates with an eAgent manager 44. The 
eAgent manager 44 then communicates with an eAgent action coordinator 46. The 
eAgent action coordinator 46 provides communication among a plurality of eAgents 48* 
60. Each of these elements 4046 is a ccmfigurable XML COM component The 
functions performed by these comi>onrats will be discussed below. The configuration 
provides a decoupled eAgent architecture in which action components can be added 
without having to recompile any code, stop and restan any services, or interrupt 
functionality in any w^y. 

Fig. 7 provides an execution flowchart for the architecture disclosed in Fig. 6. 

> Step A: 

. The eAgent manager 44 loads and reads its configuration settings documents 45. The 
configuration settings on die documents 45 inchide. which queues 26 it should 
communicate with, where selector files (to be discussed below) are located, how many 
retries to perform for each XML document, and otiier initializatira information. 

> StepB: 

The eAgent manager loads and caches selector XML.documents 47 for later use. 
XML selector documents inform the eAgent Manager which action sets to perform for 
each XML document tiiat it receives from the Inbox. The selectors use a content 
based selection usmg XSL patterns. 

> StepC: 

The eAgent manager 44 instructs die Queue Manager 42 to poll an Inbox Queue 35 in 
the message queues 26 for XML documents. The Queue Manager 42 destructively 
reads the XML document, and copies die document from the queue to an In-Process 
Queue 34 and to a log queue 37. It then sends the XML document to the eAgent 
Manager 44. 
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> Note that Step B and C occur periodicany. 

> StcpD: 

Hie eAgent manager 44 now tests the incoming XML document against each selector 
document 47 that has been loaded into the eAgent manager 44. A selector document 
47 contains one or more XSL selector patterns that are associated witib an Acti<mset 
ID. The test nivolves applying die XSL selector pattem(5) to the XML document and 
determining if any maidies were found. If matches for one or m<»^ (as configured) 
XSL selector pattern were found, then an Actionset designated by an Actionset ID 
. associated with the particular selector pattern will be executed (not m dus step). « If 
no selector pattern matches are found, then it continues to step E2. If the eAgent 
Manage 44 finds one or more Actionset(s) ID's for *Acdonset(s} to execute, it 
continues to Stq> E. In addidoi, the eAgent Manager 44 creaites a routing document, 
to which it attaches the incoming document. The purpose' of the routmg document is 
to provide tracking functionality of ^ons performed on the XML document, in 
addition to routing die document itself. 

> StepE: 

If an Acdonset ID is found (i.e., a match to a selector pattern has been determined), 
dien die eAgent Manager 44 instructs die eAgent Acdon (^rdinator 46 to load an 
Acdonset document 49 associated with the Actionset ID associated with the matched 
selector pattern in step D, and execute die acdcms specified in this Actionset document 
49. 

> StepE2: 

If the eAgent Manager found no matching selector RIc for the current XML 
document, it mstructs the Queue Manager 42 to remove die XML document from die 
In-Process Qxmt 34, and add it to die Dead-Letter Queue 33. 

> StepF: 

The Acdcmset file 49 includes at least one action, with diat action containing a ProglD 
or GUID for a relevant eAgent, plus an action document ID. Based on die Actionset 
file 49 specified in steps D and E, die eAgent Action Coordinator 46 loads an eAgent 
(48-60) specified by a ProgID for the Actionset file 49 and instructs the eAgent to 
perform the relevant task by passing it to die associated document ID. 

> StepG: 

-22- 

0137I70A2J_> ' ^ 



wo 01/37170 PCTAJSOO/31221 

The loaded eAgent reads the action documrat associated with the specified action 
document ID (from the Actionset file 49} (each eAgent has its own type of associated 
Acdon document which tells it which internal methods to call for each action specified 
by the eAgent Action Coordinator 46), and performs the requested tasks. 
> StepH: 

Once the tasks are completed, the eAgent returns any resulting data from its actions to 
the eAgent Action Coordinator 46. The eAgent coordinator 46 adds mformation to 
the routing document. Typically, this information will relate to the eAgent action, 
and may provide information on the completion or non-completion of the action by 
the eAgent. The information may also include a time-stamp for the time when the 
eAgent commenced its.action, and a time-stamp for when the eAgent completed its 
action* This information may include results from the action performed by the 
eAgent. This information may be readable from the routing document by other 
eAgents. Note that the time-stamp information provides a time history of activity for 
tracking purposes. 

• If the action was not successful, the eAgent Action Coordinator 46 informs 
the eAgent Manager 44 that the actira was not successful and passes the 
routing document and the attached XML- document to the eAgent Manager. 
It will also add information relating to this non^mpletion to the routing 
document noted above. 

• If the action was successful, the eAgent Action Coordinator adds this 
information to the routing document, and checks if this was die last action 
specified in the Actionset 

• If it was not the last action^ step F is performed again for the next action in 
the Actionset* 

• . If it was die last action, tbra the eAgent Action Coordmator 46 checks if 

the current Actionset is die last Actionset specified m the original selector 
file for this XML document. 

• If it was not die last Actionset, die eAgent Action Coordinator 46 moves to 
step E for die next Acticwiset. 

• If this was the last Actionset, it passes the routing document with the 
included original XML Document back to the eAgent Manager 44. As 
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noted above, the roudng document will include infonnation on whether all 
the Acdonsets for this XML document .were successful or not* 

• If the Actionsets were not successful, the eAgent Manager performs step II 
and cither writes to the error queue 30 or the retry queue 31, dq>ending on 
the eAgent manager configuration setdngs, and removes the document 
from the in*process queue 34. 

• If the ActioDset(s) were successful, the eAgent Manager 44 performs stq? 
12, i«e., it sends the routing document widi the original document and 
pertinent informaticKi attached to a journal queue 32, and deletes the 
document from fte in-process queue 34. 

• In addition, as noted above, time^amps are added to the routing document . 
detailing when the zx^on was initiated and ^en complete. 

> Step II: 

If the Actionsets were not successful, the eAgent Manager sends the routing document 
to the Error Queue 30, or to the Retry Queue 3h The ccmfiguration setdngs read in 
step A specify how many times an acdon should be retried and bow long to wait 
between each retry. This determines whether die eAgent Manager 44 sends the XML 
document to the Retry Queue 31 or the Error Queue 30. The eAgent Manager 44 
also deletes the routing document from the In-Process Queue 34 since it is no longer . 
in process. 

> Step 12: 

If the Actionsets were successftil, tbe eAgent ^letes the XML document form the In- 
Process Queue, and places it in the Journal Queue, indicating success (and logging die 
document for auditing purposes). 

To summarize the organizaticm, each selector file includes cme or more patterns, 
and will be triggered when one or moie of Aese patterns are matched in the incoming 
document Tbeselecdonof which and how many patterns must be matched is 
determined by die processing designer. Each selector file inclucfes only one Actionset 
(although Acdonsets can be nested). Each Actionset includes one or more actions. 
Each acdon includes die designation of one eAgent ID and an action document ID. 

It should be noted that Actionsets may include branching commands, repetition 
commands, parallel execution commands, and time controlled execution commands. 
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The presrat invention also encompasses a system shown in Fig. 20 for 
perfonning actions on documents m a computing environment. The system comprises 
a selector file database 300 containing a plurality of selector files, with each selector 
file including one or more patterns. The system further comprises an Actionset 
5 ^btabase 302 including a phtrality of Actionsets, with each Actionset including one or 
more actions that reference an eAgent ID and an action document ID. Each selector 
file is associated with exactly one Actionset (but there may be nesting of Actionsets). 
' The system fiirther includes an eAgent q>ecific action document database 304 
containing a plurality of action documents that are specific to eAgents. Note that each 
10 Acdonset is associated with at least one action document. 

The system may fiirther include at least one creation module for creating and/or 
manipulating entries in one or more of the databases 300*304, : 

Hie syst&m may fiir^r comprise a processing component 306 programmed with 
code for allowing a designer to select at least one of the selector files from the 
IS selector file database 300, code for allowing the designer to select at least one of the 
Actionsets firom the Acdonset database 302, code for specifying at least one eAgent 
specific abtion document from the eAgent specific action document database 304, code 
for imking the 9>ecified selector file firom the database 300 with the specified 
Actionset from the database 302, and code for linking the specified Actionset with the 
20 q>ecified acdon document. 

. Referring now to Fig. 8, there is shown a system block diagram of an integrated 
development environment (IDE) architecture in accordance with the present invention. 
The IDE architecture of Fig. 8 is based on a distributed, n-tier architecture, that allows 
sharing of both user interface and business components with centralized, dynamic 
25 . configuration and automatic distribution. This is described in detail in the following 
sections. Note that the term ''tiered ardiitecture'' means that a component in a given tier 
can communicate with other components in the same tier or with components in 
immediately adjacent tiers only. 

Distributed - Accessing FUes/XML documents over the Internet 
30 Acces^g files/XML documents is performed using a file system abstraction layer 

100, an ASP File System client implementation 102 and an ASP File System server 
implementation 104. 
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The file system abstracdon layer 100 is an interface that defines and contains 
common file manipulation functions, such as reading, writing and deleting 
files/documents. 

The ASP File System client implementation 102 implements an interface and 
5 communication between the file system abstraction layer 100 and the server 
implementadon 104 using its own XML^based simple file access protocol (SFAP). SFAP 
includes the ccRnmands as defined in the file system abstracdon layer in an XML format. 

The server implementation 104 perfomis acoial file manipuladcm, e.g. reading a 
file and communicates with the client-^side implementation 102 using the SFAP. 
10 Therefore, the user (i.e., the business components) of die file system abstracticm 

layer 100 can manipulate files/XML documents over the Internet simply by using the 
functions of the file system abstraction layer. 

N-ders 

Presentation Host Her - IDE host. 
IS An IDE host tier 110 is shown in the figure defines an envircHimeht into which 

different user interfoce components (IDE components) can be plugged in. The host does 
not provide any end user functionality itself, hat defines a standard set of interfaces for 
IDE components to implement, induding 

. a) A shared library of user interfece and logic elements, including jtreeview, 
20 listview, toolbar controls. 

b) A consistent navigation system, regardless of the IDE component. 

c) A set of ''standard acticms," such as new/edit/delete 

d) Provision to supply custom controls. 

e) Ability to have varying number of IDE components hosted. 
2S Important additicmal aspects of this configuration include: 

> Implemented bodi standalone and inside a browser. 

> Support for standard actions 

> Support for sharing business compcments 

Note from die above, that along with the shared user interface and logic code 
.30 ccxnponents, the presentation host 1 10 includes code for reading any IDE componrat code 
and business logic component code that may be defined by an IDE configuratira 107. 
The IDE configuration block 107 stcnres a file for each of a plurality of different roles, 
with the file for each different role including the ID^s and other ^prc^riate information 
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for the components that are to be loaded into the computing resource or browser that is to 
. perform that given role. 

Presentation Controller Tier - IDE componoEits 

The IDE components 108 implement the interfaces defined in the IDE host 110 
5 and are the components that actually define the mteractions with the end user, and include 
such IDE Components as eAgent Actions code. Form Schema code, Queries code, and 
Regular Expressions code. They do not include the business or sq;>plicati6n logic. He 
IDE components code is typically loaded to the browser or other computing resource by 
the presentation host 110. The IDE components 108 also typically have associated 
10 custom controls. Custom controls are required for die result pane of the window (right 
hand side of the IDE) if some other view than the listview is to be shown. 
Bu^ess Logic Tier • Business Components 

The business componmts 106 implement the business rules/applicadon logic for 
that ccxnponent for its associated component 108 m the presentation controller der. By 
IS way of example, the logic for the select query component in the business logic tier might 
include a selectquery class with a mediod "cheddfvalid" that checks if all necessary 
information has been provided and all data entered is valid. Likewise, the logic for the 
form schema component in the business logic tier- might include classes for the 
relationships between forms, pages, sections and fields, where these classes have 
20 attributes that describe the objects, such as a caption attribute of the field class. 
Data Access Her 

This tier includes code to allow the bisiness component code to read and write 
information to/from a computing resource. In a preferred embodiment, the tier includes 
the file system abstraction layer 100, die file system client implementation 102, and the 
25 file system server implementation 104 described above. 
Dataller 

This tier includes an eAgent repository 105 which includes selector files/Actionset 
and eAgent specific action document databases, the schema library 10, the query library 
12, the validation library (regular expressions) 14, and the IDE configuration 107. These 
30 repositories/libraries are where die acmal XML documents reside. This could be in die 
file system or in an XML database. 

Sharing of User Interface Componmts 

-27- 



wo 01/37170 



PCTAJSOO/31221 



The IDE bost 1 10 allows the sharing amcmg components 108 of common interface 
elements, such as toolbar, treeview and Ustview. In regards to the treeview, the IDE host 
110 also creates a "virtual root" for each IDE component, so that each IDE component 
may only see and manipulate its part of the tree. 
S Sharing of IDE compments allows for a lower fooQ>rint, e.g., histead of Ave 

treeview controls, only one is used 

Sharing of Business Components 

Unlike any other systrai* die IDE host 110 has the explicit ^ility of using 
business components 106 to implement the business logic of the IDE components and the 
10 ability to share diem between different IDE, components. As the exact same 
objects/instances are sbsired . among different IDE components there are no 
syndhronizadon delays. 

The instancing of business ccmponents is ^refore not done inside the IDE 
components but instead from the IDE host 
IS A configuration XML document, that is located in the IDE configuration 

component 107 defmes: 

> whidi IDE and business ccxnponents are to be loaded by the presentation bost 1 10 
loading code; 

> which IDE ccHnpcments 108 are associated with which business components 106 
20 > any dependencies between bas'mess components; 

> other configuration settings for eadi business component. 

U^g this information the IDE host 110 creates instamres of the bushicss 
components in the prefer order and passes them and the relevant configuration 
information to the IDE components 108. whidi in turn pass the relevant infonnadon to 
25 their business compottrat(s} 106. 

Note: the IDE host may be componentized. By way of example, in the preferred 
embodiment the IDE host is acDially made up itself of at least 3 different components; a 
control component, a communications and a configuradon ramponent. 
Centralized, dynamic configuration 
30 The configuration is centralized, i.e. it is set by the Web Server or other 

appropriate computing resource via the IDE configuration block 107 which lists the 
components that are to be loaded to a given browser or other comfrnting resource to carry 
out a role. Thus, there is no need to do the configuration on. each client machine. This is 
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because the configuration XML document resides on the AVeb Server in the IDE 
configuration block 107. 

Note that because of this architecture, the configuration of any given browser or 
other computing resource is dynamic, i.e*, the IDE host 110 does not need to be 
S recompiled if more or less IDB components are to be loaded. The number of IDE (and 
taisiness) components to load is determined at runtime/stamip. 
Automatic IMstributioD 

By using an ActiveX based solution running in Internet Explorer S or another 
brow^r software compatible with a data-centric hierarchical storage and retrieval 
10 mechanism, both installing and upgrading is handled automatically. This is handled by 
Internet Explorer, i.e*, IE 5 checks at the beginning whether the components are 
registered on the machme or if the newest versim is on the machine and if not it 
automatically installs or upgrades the mdividual components onto the client machine. ' 
To summarize one aspect of the present invention, there is provided an integrated 
IS development environment method, comprising the steps of: loading onto a computer 
resource code in a tiered architecture compri^g: a presentation host tier that includes 
presentation host code, the presentation host code uicluding shared user interfece and 
logic code components* code for reading a IDE configuration, and code for loading any 
IDE component code and business logic components code as defined in the IDE 
20 configuration; an IDE component tier, including at least one IDE component code loaded 
by the presentation host on the user^-interfece program, the IDE component code 
including a user interfiace; a business logic component tier, mcluding at least one business 
logic component code loaded by the presentation host on tbt user-interface program, the 
business logic component code defimng the interrelationships between objects represented 
25 in the user interface; a data access abstraction layer tier, inchiding a data access 
abstraction layer code that allows iKisiness components code to read and write information 
to/from a computing resource; and conmmnicating with a remote computing resource 
through use of the data access abstraction kiyer. 

Process Woricflow Diagram of Form Publishing Process 
30 Referring now to Fig. 5 and Fig. 21, there is shown a workflow diagram for a 

forms publishing process and a schematic diagram of the IDE - server operation, 
respectively. Witii reference to Fig. 5, the process is as follows: 
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> After saving a new fonn in exeoidon block 200, the user is prompted in execution 
block 202 to publish to the web or o^r locatton. 

> If he chooses yes, then the publishing process is initiated 

> Step A: 

5 The publishing wizard starts up and requests a list of templates from the '"publish.aq^" 
page. Note: this file can be named differently. 

> Stq>B: 

The "publish.asp* page reads the content from templates.xml and sends the liist of 
available templates via the publishing wizard. 
10 > StcpC: 

The publishing wizard presents the templates and after the user has chosen cme, 
requests template q)ecific questions and a list of available publishing folders from 
"publish .asp" 

> StepD: 

IS The ''publish.asp" page opens the specific "template.xmr file designated by the 

responses to the template q)ecific questions, plus (^)ening die '^folders.xml* for the 
available publishing folders. It then sends this information to the publishing wizard. 

> Stq)E: 

The publishing wizard presents the template specific questk>ns, collects the answers, 
20 presents the available publishing folders and lets the user select one. As the last sicp 
the user may give the published form a name and capticm; the default is the name and 
caption of the schema* 

> StcpF: 

The ''publish.asp" page package all of the needed information into one XML 
2S docum&tt and sends it for processing. This may be synchronous as shown in the 
diagram, or asynchronous via a queue. 

> StepG: 

The publishing component copies (processed) template items in selected publishing 
folder for later display. 

30 Referring now to Figs. 9-19, schematic diagrams of various schema are 

illustrated. Fig. 9 shows a forms sdiema. Fig. 10 shows a regular expressions schema. 
Fig. 11 Shows a select query schema. Figs. 12 and 13 show template schema. Fig. 14 
shows a publishfolders schema. Rg. 15 shows an IDE configuration schema. Fig. 16 
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shows an XML selector schema. Fig. .17 shows an Actionset schema. Fig. 18 shows an 
action Query eAgent schema. Fig. 19 shows a Queue Config schema. The various 
element/attribute descriptions are listed below. 

Note: bold-faced items denote XML elements, non-bold-faced items denote XML 



5 attributes. 



Element/Attribute 


Description 


fonn 


. The hi^est level element acting as a container for 
all of the data items that make up the intended form. 


name 


Unique identifier for the form. May only contain 
characters, no spaces or special characters allowed. 


option 


Title of the fonn, may contain spaces and special 
characters. 


helptext 


Informative text such as instructicms on what diis 
form is about. 


page 


A subdivision of a form that typically is di^layed as 
a separate pa^e in the browser. 


name 


Uni^ie identifier for the page. May only contain 
characters, no spaces or special characters allowed. 


capdon 


Title of (he page, may contain q)aces and special 
characters. 


helptext 


Informative text such as instructions on what this 
page is about. 


section 


A subdivision of a page that omtains a number of 
fields for the user to enter. 


name 


Unique identifier for the section. May only contain 
characters, no spaces or special characters allowed. 


caption 


Ude of the section, may contain spaces and fecial 
characters. If there is more dum one section per 
page, the sections must contain a caption attribute, 
otherwise it is ignored. 


helptext 


Informative text such as instructions on what diis 
section is about. 


isvalid 


true/false - flag reflecting the status of the section: 
true if the items within the group have no validation 
errors assodated with the item, false otherwi^ 


errormessage 


The text that will be displayed if a validation rule 
has been broken 


jscriptvalidation 


A validation rule written in JavaScript that is to be 
evaluated for this section. No direct access to 
outside resources such as databases, etc. is needed. 


jscriptextemalvalidation 


A validation rule written in JavaScript diat is to be . 
evahiated for this section. Direct access to outside 
resources such as databases, etc. is needed. 


captionrow 


tnte if the section is to be displayed with the 
captions of all of the first element in each row of 
items on a separate row above the rest of the items 
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fidd 


A data entry unit, which may be di^layed in 
different fashions. A field is an entity that accepts 
user input. 


name 


Unique id^ttfier for the field. May only contain 
characters and digits (not as first letter), no ^aces 
or special characters allowed. 


caption 


Cation of this field, may contain q>aces and ^)ecial 
characters. 


hdptext 


Infcnrmadve text sach as instructicHis on what to 
enter in this field. 


isvalid 


true/false • flae reflecting the status of the item* 
tn» if no validadoa rules for this field have been 
violated; false otherwise. 




validation rule for Ais field has been violated. 


VUluCjUttupiC 




jsbriptvalidation . 


A validation rute written in JavaScript diat is to be 
evoJUaieu lor uus neio. no oireci access to outside 
resources such as databases, etc., is needed. 


J SCnpiCAiCniaJValluaUQll 


n. VailQaUOU Iul6 WTlUCn Um JaVadvripi ulal IS JO DC 
CVaJUalCU IVl UUa UCiU* L^ilCU. oU4;C55 lO 1X1151 UC 


minlengtb 


The minunam number of characters required for a 
field. 


UulAICIlgUl 


field 


required 


False if empty entries into this field are allowed^ 
true otherwise 


minvalue 


Minimum value allowed for this field. 


maxvalue 


Maximum value allowed for this field 


c^italizadon 


Provide for automatic formatting of itqmt, e.g. 
aq>italize all» make all lowercase or put into proper 
case 




Allowed innut format 


regcxvalidation 


A regular expression pattern that is to be applied to 
the field value input* 


regexmodifier 


A mo(fifying value that changes how the regular 

#»TnrAssinn Ift annliftd tn fiftld value ^i* 

(incasesensitive) will check the input value without 
reeard to and * 6* ( dobal) will check for all 
instances of the pattern (as opposed to stc^mg at 
the first match). 


text 


The text node for the field. It contains the default 
value m the begiiining and will cmtain the entered 
data from the end user as soon as the user enters 
data. 


display 


The display element provides basic information on 
how to display the field. 


samerow 


true if the item is to be displayed on the same row 
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with the previous field. Not inchided if the field is | 
the first field of a row 1 


nowrap 


true if the values associated with the display of the 

field arft allfWAd tn wran tn thi» npYt lini^ 'faIcA 1 

otherwise | 


WlUUi 


width of the innut control in chanicf^^ 1 


controltype 


Name used to determine how to display the field 
element that will be used to Bccfpt user input. 


cols 


Number of characters across to be displayed for a 

ICAloiCa OlSpiay. . | 


rows 


Number of characters down to be displayed for a 
iCAiarea oispiay* | 


luuiupicseiccc 


uue ix rouiupie cnecKooxes tn a group or i 
cucw&uoACa or sciecuoiis in a puii*€iown iisi may oe 1 
selected. Not included if only a single value may be 
cnoscn» | 


selectprompt 


Text to be shown as the first field in a pull-down list 
10 prompi me user lo seieci an eniry* | 


minyear 


Mmimum year displayed in datepicker year select 


maxyear 


Maximum year diq;)Iayed in datepicker year select | 


multitextformat 


Format specifying how many textboxes to show and 
relevant properties, such as maxlengtfa. | 


multi 


true if more than one field are to be shown in a 
row. 


rownumber 


A number identifying the sequence in which the 
fields will be displayed down the section. | 


rowindex 


A number identifying the sequence in which the 
neios wiii De aispiayeo across tne page. | 


entries 


jrroviues a iisi oi possioie vanies lor mis rieia, i 
which may be used for display and validation 


ISiTUinQO 


uuc 11 A ({ucry lu a uaiauasc IS rci|uirea | 


qdef 


D/Name of the query definition containing the 

niiAfv to tiRftim flip li^t of ^ntTii*^ 1 


entry 


A single entry. 


aQv/W 


luc icxL U/ uc luspiajrcu U/ Ulc cuu uscr wnicn may I 

V* /liffiprAnt "fironi fTiA ffitpmftl'vdliiA ctnrA/f 1 


value 


The value of that entry. 


parauieier 


i\ paiani&ier lur um? wiui queried uiai ruruier i 


nam* 


name oi uic paiaincicr. rausi concspona lO uie | 
name of the parameter for the select query 


value 


The value for this parameter. 


custom 


An element that allows addition of custom datai to 
any field or section as a name-value pair. 


name 


The name of the custom entry 


value 


The value of the custom entry 


data 


This element is a container for system^ temp and 
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user data that are filled at runtime. 




Data needed by tbe system, such as path setting 


guid 


A globally unique identifier that is used to identify a 
specific instance of a form. 


temp 


Temporary data needed by the system or the user 


pagraumber 


Number of the current page being displayed 


serverpatb 


URL of tiie web server containing the application 


schemapatfa 


Location of tbe directory that contains the schema. 


xsiimagqKUh 


Location of the directory containing the images used 
by the XSL files 


user 1 Element to place custom data regarding sections. 


7. Regular Expression 


. £leinent/Attribute 


Description 


regexdb 


Root element, just, a contamer of regex elements 


rcgejc 


Contains a regular expression 


name 


The name of the regular expression. May only 
contain characters* no spades or special characters 
allowed. Must be unique. 


pattern 


Tbe pattern that describes what is looked for. 


globalseaich 


A regular e3q>ression modifier that defines whether 
the pattern shall q>ply to all of tbe string or only 
part of it 


casesensitive 


A regular expression modifier that q>ecifies whether 
to take case sensitivity into account or not 


description 


A descripticm of the regular expression that explains 
what it is about 


validexample 


An valid example of an entry. 


enortext 


Text to be displayed when an entry does not . 
conform to the pattem 


regeactest 


Contains the information necessary to perform tests 
and quality assurance against tbe pattem. 


testvahie 


A value that is to be tested/evahiated against the 
current regular expression to determme validity. 


expectedresult 


True when <me expects die testvalue to be a valid 
entry, fidse when one expects the testvahie to be not 
valid. 


8. Select Query 


Element/Attribute 


Descripti<m 


selectqoery 


The selectquery itself. Root element 


conn 


Tbe name of the connection to use. Thisism^ped 
to a connection file, ^)ecifical]y to a Microsoft Data 
Link file with the extension UDL 


type 


The type of query. This is the same as ADO' s 
ConunandTypeEnum. The possible vahies are: 
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1 - Text 

2 - Table 

4 - Stored Procedure 

8 - Unknown 

256-File 

512 - TablcDirect 


commaodtimeaut 


Number of seconds until this command times out 


descriptioQ 


description of this select query 


parameters 


Container of parameter elements 


parameter 


Constitutes the one parameter that can be passed at 
nintirae to modify the query text . 


id 


unique parameter name identifying this parameter 


description 


description of tius parameter 


datatype 


The data type of this parameter 


min 


The minimum value for tius parameter 


max 


The maxhnum value for this parameter 


example 


An example for a value passed to this parameter 


autofonnat 


Specifies whether or not the parameter should be 
autoformatted, i«e« stripped of leading and trailing 
white spaces and that smgle quotes be replaced with 
2 single quotes. 


textnode 


is not an element but is mentioned here because in 
this case more tiian one textnode may be used. This 
contains tiie actual query text» e.g. ''Select from 
authors*" 


refparameter 


a reference to a defined parameter, that shall be 
replaced at runtime with the passed value . 


id 


the id of the parameter 


9, Execute Select Query (ValSelect) 


Element/Attribute 


Description , 


executeselectquery 


The executequery itself. Root element 


location 


Full path to die FOLDER where die query 
definition file resides (Note that die UDL 
connection file required for die query must also 
reside there) 


name 


Name of the query definition file (without die 
extension) 


cursortype 


ADO cursor type. Defaults to forward-only (0) 


parameter 


Each parameter needed for the query is in its own 
element 


name 


Name (id) of the parameter 


value 


Value of the parameter 


10. Templates 


Element/Attribute | 


Description | 



••-35- 



wo 01/J7170 



PCT/USO0/JJ221 



templates 


Root element 


template 


Element describing a particular template 


name 


Name of tiie template, e.g. **SMC Look* 


path. 


Pull path to the folder where the template resides, 
e.g. "c:\tempIates\smclook* 


IL Template 


Element/Attribute 


Description 


tmslftte 


The tcmolate itself. Root element. 


parameters 


Element crataining parameters. 


parBmecer 


Crivuicul QCodKiing wuc paiaincicr* 


id 


Attribute that identifies a particular parameter. 


question 


Attnoute contammg ine <iue5ticHi the user is asked to 
describe this parameter, e.g. *Does this form have a 
oanner logo miage/ 


type 


The type of parameter - text, boolean or list 


usuEcm 


If die parameter has a list of items associated with 
it. 


sbow 


The text to be displayed as one entry. 


value 


The internal vahie stored 


templateltems 


This element contains ail the template itmis that are 
to be copied 


tcmplatettan 


Each item of the template 


id 


The identifier for the template it^ - the name of 
die file, e.g. **CSvasp* 


scanfozparameters 


Boolean attribute set to true if there are parameters 
to be replaced by values specified by the user. 


keq>name 


Boolean value specifying whether to change the 
name of die item. 


subfolder 


The name of the subfolder where the item resides (if 
the item is in a subfolder) 


allowovemrite 


Boolean value specifying if die destination file 
should be overwritten if one already exists. 


]2«. Publishfolders 


Element/Attribute 


Description 


publishfolders 


The publishfolders root element. 


folder 


The element describmg one publishing folder 


name 


Descriptive name of the folder e.g. "SMC Internal 
Forms" . 


padi 


Full path to the folder, e.g. 
•*c:\inctiMib\wwwroot\smcintforms" 


urlrclativetowebserverroot 


The url of the publishing <testination folder relative 
to die ropt of the webserver, for example if die foil 
url to die publishing folder is: 
bttp://www.somepIace,com/SomeRoot/SomeSub/Ta 
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m 

The uriielativetowebserverroot attribute value will 
be: 

SomeRoot/SomeSub/Target 


13. IDE Configuration 


Element/Attribute 


Description 


lOgCOflTlg 


liic AUG vunxiguiauufj r(X/( cicnienu 


ideoomponfiBts 


ine rool element tor aji ot toe lutt components 


ideoomponent 


(tee single IDE compraent, which may have one or 
more business components on which it is dependent 
on 


progid 


The program ID.of the IDE cqmponmt, e.g« 
WTKIDECQueries.CIDEQueries 


biismesscompoiient , . 


Child .of idecomponent, referencing a business 
component as defined under "businessoomponents" 


progid 


Hie program ID of the business component 


config 


Child of ideoomponent. Allows custom subelenients 
which include configuration settings for a IDE 
component, sudi as display preferraces. 


bosinesscomponents 


The root element for the business components 


businesscomponent 


Child of business component^ defines a business 
component* which may be used by one or more 
GUI components. 


progid 


The program ID of the business component. 


bu^esscomponent 


A child of business component, indicating a 
dependant business componrat. 


progid 


Hie program ID of the dependant business 
component 


config. 


Child of businesscomponent. Allows custom 
sobelements which include configuration settings for 
a business component, such as path settings. 


14. XML Selector 


Element/Attribute 


Description 


selector 


Root element that defines, just a container of regex 
elements 


Acdonsetid 


ID of the Actionset to execute if the required XSL 
patterns match the XML document. 


matchall 


If true then all of the XSL patterns have to be 
successful, if false then only one pattern needs to 
match. 


priority 


A numb^ specifying how to deal with the Actionsbt 
if the patterns sq)ply. The lower the number the 
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greater the priority. Actionsets with hi^r priorities 
are necuted first. 


pattem 


Oidy ccmtains a node, that contains the XSL 
pattern that selects one more nodes from the XML 
document 


15. Acticmset 


Element/Attribute 


Description 


Actionset 


Root elsmeat that contains the references to the 
actioos to execute on an XML document. 


action 


Single action that is to be executed on an XML 
documrat 


progid 


The progiam id of die eAgeat that deals with this 
action. 


actionid 


The id of the action to execute 



16» Action Qiery 



Element/Attribute 


Description 


actionquery 


The actionqueiy itself. Root element. 


conn 


The name of the connection to use. This is mapped 
to a connection file, specifically to a Microsoft Data 
Link file with the extension .UDL 


type 


The type of query. This is die same as ADO's 
CommandTypeEnum. The possible values are: 

1- Text 

2- Tablc 

4 - Stored Procedure 
8 - Unknown 
256 -FUe 
512-TableDirect 


commandtimeout 


Number of seconds until this command times cut 


description 


description of this select query 


parameters 


Container of parameter elements 


parameter 


Constitutes die one parameter diat can be passed at 
runtime to modify the query text 


id 


unique parameter name identif^g this parameter 


description 


description of this parameter 


datatype 


The data type of this parameter 


min 


The minimum value for tiiis parameter 


max 


The maximum value for this parameter 


example 


An exansple for a value passed to this parameter 


autoformat 


Specifies whether or not the parameter should be 
autoformatted, i.e. stripped of leading and trailing 
wUte qyaces and that single quotes be replaced with 
2 single quotes. 
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Statement 


Unlike a select query an action query may contain 
more than one statement, that's why dbere is an 
explicit statement element. 


textnode 


is not an eiraient but is mentioned here because in 
this case more than one textnode may be used. This 
contains the actual query text, e.g^ "delete * from 
authors" 


re^parameter 


a reference to a defined parameter, that shall be 
replaced at runtime with the passed value 


id 


the id of the pajrameter 



10 



15 



20 



25 



30 



Form Templates— Purpose 

The putpose of fonn templates is to have a sepaizre rq>ositoiy for the look and 
feel of the HTML pages in ix^di the fonns will be displayed. 

Sample Folder S^cture 
mfltbrary 

T 
I- 

— templates 
templates.xml 



— miages 



-CSS 



ssscript 
— csscript 



SMCLook 

Main.asp (required file, must be diere and must have that name) 
CS.ASP 
SS.ASP 

template.xmi (required file, must be there and must have that name) 



— SmcSciDisplay 
pagebanner.btm (in the example below, this one gets copied) 
smclogo.gif (in the example below, this one does not get copied, because there is 
35 no < templateitem. for it) 
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Note: SMCLogo.gif could be in the images folder, but that's up to the templates designer 

Teniiriates«xml 

S <ten9lates> 

< template name»*'SMC Look" foiders''c:\templaies\smclook''/> 
<template names''NIH Look" foIder»"c:\teixq)Iates\nihIook7> 
</vmplztt$> 

10 TaQplate.xnil 

<template> 
<parameters> 

<parameter ids"fomic(mtact** quesdm=: "Please enter the eMail addiess for the 
15 form contact" type«='tcxtV> 

, <:parameter id-"showpictures" (iuesticm=*'Do you wish to show pictures for tfiis 
form?" type= "boolean"/ > 

<parameter id="colorscheme" quesdcm- "Please select the color schenie you 
wisb to choose" type«"list" > 
20 <listitcm name «^ "golden" vahie«"r/ > 

<listitem name^rgreen" vahie-"2"</ > 
< /parameter > 
< /parameters > 
< templateitems > 

25 < t^plateitem id= "CS, ASP" scanforparameters=« "true" keepname=s "felse" 

subfolder**"" alIawoverwrite«= "false"/ > 

<templateitBm id»"pagebanner.htm" scaoforpstrameters-^felse" 
subfolder^'SrocSciDi^Iay" keq>name=^"true" allowoverwrite""felse"/> 

< templateitem id» "pathsetting3js.a$p" scanforparaiiieters ^ "true" 
30 folder=s''Loca]ServerS!deScript"keq>name»"true" 

allowoverwritC""felse"/> 

</templatei^s> 
</template> 

35 

Note: 

- Maui. ASP must exist and will be renamed according to the name chosen by die forms 
designer/publisher. 

- Per the definidcHi used in this context, a templateitem is one that needs to be copied. 
40 - All templateitems must reside inside or below the template folder* 

Note: 

- The name of Aie schema must be provided by the pubVishing wizard (no user mput 
necessary) 

45 - The name of the publishingfol^, where the ASP pages will be cq>ied to, is provided 
by die publish.ASP page, (the pablishingfolder is the one where main.asp and all other 
relevant items will be copied to) 

- name of the template is provided by user (earlier on) 



•40- 



wo 01/37170 PCT/USO0/J1221 

- The name of the resulting ASP page / fonn (e.g. Leave.ASP) is provided by the end 
user. It does not however have to be put into the template, because this is always needed. 

jPublishing Process 

5 

The publishing process was previously described in detail in relation to Fig. 5. . The 
following material supplements that description* 

Liitiatioii 

10 1. First, the user saves the form« The user will be prompted to start the publishing 
wizard. If yes is selected then the wizard is started. 
2. User selects the form and diooses "publish to web. " 



15 



list of publishing folders 

Per *'publish.a^'* there diall be one XML file that lists all available publishing folders. It 
should look as follows: 



< folders > 

20 < folder name- "General Forms" path=="c:\inetpub\wwwroot\generalforms"/ > 

< folder ruune= "HR Forms" path= "c:\inetpubVwwwroot\hrforms"/> 
< /folders > 



Communication between VB wizard and publish.asp 



25 



Step 1: Present list of templates to user User selects one. 

Step 2: If there are any parameters, present corresponding questions and let user enter 
them one by (X)e. 

Step 3: If there is more than one publishing folder, present list of publishing folders. 
30 Step 4: Display name of the resulting form. (Default to name of schema). User clicks 
Publish. 

Note: the path to ^publish.asp*' is set in the config file and can also be called a different 
name. 

35 Example Operations 

L Get a list of templates: 
<request> 

< action > GetTemplatcsUst < /action > 
40 </request> 

<response> 

<templates> 

< template name = "SMC Look"/ > 
45 <templatename="NlHLook7> 
< /templates > 
< /refuse > 
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I Note: the folder attribute should not be sent to the client to hide this mfoimaticHi (e.g. 
use database later on instead of folcters) 

2« Get parameters for specific template and the list of publishing folders 

5 

< request > 

< action > GetParametersAndPublisfaingFoiders < /acticm > 

< parameter > hfn5U)ok < /parameter > 
< /request > 

10 

<response> 

<parameters> 

<parameter id-''formcontact' question^ "Please enter the eMail address 
for die form contact** type » "text"/ > 
15 <parameter id- ''sbowpictures" question's "Do you wish to show pictures 

for this form?" typc» •boolean"/ > 

< parameter id-"colorscheme" question = "Please select the color scheme you 
wish to choose" type = "list" > 

<Iistitem show=* "golden**/ > 
20 <Iistitcm show="red"/ > 

< /parameter > 
< /parameters > 

< folders > 

< folder name= "General Forms"/ > 
25 < folder name= "HR Forms"/> 

< /folders > 
< /response > 

3. 

30 <reque^> 

< action > formexists < /action > 

< publishingfolder > General Forms < ^blishingfolder > 

< fommame > Leave < /forroname > 
</request> 

35 

if form exists ... 
< response > true < /response > 

else 

40 < response > false </response> 
4. 

<request> 

< action > publish < /action > 

45 < template > NihLook< /template > 

< formschemaname > Leave < fonnschemaname > 

< publishingfolder > General Forms </publ .MungfoIder> 

< formtide > Leave ^plication < /formtitle > 
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< fomschemanaine > I^ve < /fomschemaname > 

< parameters > 

< parameter id- "formcontact " > Sanjeevig^Science- 
Managemeaucom < /parameter > 

5 <parameter id=showpictores > true < parameter > 

< parameter id= "colorscheme" > golden < /parameter > 
< /parameters > 

</request> 

10 if sucx:essful: 
<response/> 

else: 

<excepdon id=^"15*>could not access file c:... </exception> 
Processiag 

In a preferred embodiment, the processing is implemented right away in a 
synchronous manner. However, this will not always be the case, e-g., when the 
20 publishing needs to be reviewed and approved before it may be published. In this case it 
would first get passed to the authorizing person, and only when ^proved would the 
actual publishing be performed* 

To enable easy switching to a disconnected proce^sising, all of the data that is 
required for the actual processing of die publicadon is put into one XML document and 
25 passed to a 'publish" function. This will allow the publishing process to remain identical 
when there is a switch to asym;hronou5 processing. 

The processing that then takes place first scans and then copies die "Main.ASP" 
file, and then any other templateitems, and creates subfolders as needed. 

Each publication is joumalled as part of the processing, so that this can be used 
30 later for evaluation, trackmg and other purposes. The joumaling should preferably 
include all of the informaticm regarding a publication. 
Sample ASP page 

<html> 
35 <% 

binShowPictures = <replaccme id=''showpictures''> </repIaceme> 
If blnShowPicmres Then 
%> 

<irag. 

40 <% 

Else 

%> 
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For questions please contact < replaceme id = "fonncontact " > < /rq>laceme > 
</html> 

5 

Absolute TS. Relative Paths 

The template designs uses an "iftnclude file^..* for template items fliat get 
copied (and uses a relative path setting for tfaiis), and uses a '*#inclu(fe virtual for files 
10 that not to be cq>ied. 

Similarly^ for images one would use an absolute path if they are to remain in the 
template folder. However, care has to be taken not to hardwire the actual web servet 
patb» as odierwise one would have to change several settings if one wanted to move from 
one server to another, such as for debugging. Instead, one should use the 
IS WEBSERVERPATH variable that is set in pathsetdngsjs^asp 
An example of an absdute p^: 

<img src="< %=WEBSERVERPATH«>/ mflibrary/images/logos/oihlogo.gir ah 
width=-110- height^"103" align=="top"> 

20 

An example of a relative path: 

<img $rc»".*/tmages/logos/niUogo.gir alt width=''110'' heigbt»"103'' align» *top" > 
Note: the same applies to other files with a source attribute, such as Script. 

25 

The present invention is a unique product, which mcludes a rich Integrated Development 
Environment (IDE), and a powerful luntime environment. The mvention allows users to 
create powerful web based iqyplications using, by way of example, a 4GL Rapid 
Application Developmmt (RAD) environment Hie invention is uni^e in a variety of 
30 important aspects whidi inchide the following: 

• One aspect is a hierarchical gr^hical user inter&ce (GUI) diat focuses on content 

mstead of on presentation, unlOce other tools of this kind, which focus <m layout and 

presentation and are ttierefore far more time consuming. Such odier tools are £ar 

more tirne-consuming to maintain for the same reason. 
35 • One aspect of the invention is the ease of creation AND maintenance of applications, 

and allows for easy roise of form pages/secdons/elements metadata, and presentation 

information as well as easy maintenance of these items. 
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• One aspect of the invention focuses on complete separation of tiers in every aspect of 
the product. This is done to enable independent creation and niaintenance of distinctly 
sq>arate parts of an application* It allows non-technical people to develop the 
metadata of web based applications, leaving a minimal amount of work for the web 
develq)ers (templates and regular expressions) and the database develq>ers (database 
queries). 

For this aspect, each of the following is stored in a different XML document and is 
accessed from different tools in the IDE. Each can therefore be performed by 
different people^ and can be maintained separately: 

• the database configuration information 

• the database queries 

• the application presentation templates 
« the application metadata 

• the field validation code 

• custom input patterns/masks for composite fields 

• The invention does not require the use of a ^>ecialized 'viewer* by users of 
applications developed using the invration. The only 'viewer* required Is a standard 
browser. 

• The invention uses two different presentations of die same metadata to support XML» 
enabled browsers and ncm-XML^nabled browsers without any additional development 
efifbrt by users of the program. XML-enabled browsers perform most processing on 
the client and, due to less roundtrips to the server^ have greatiy improved response . 
times. 

« The inventi(Hi uses a queue-based n-tier architecture to increase scalability anid 
reliability. 

• The mvention uses the eAgent Architecture on the back end to perform multiple 
scalable and customizable actions and work flows using data obtained from the 
Invention applications* 

• _ 

The following lists more details of the variety of new aspects of the present invention. 
1) Integrated Deyelopment fiavironment 
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The Inventive Integrated Develq)ment Environment (IDE) allows users to ^iddy 
create and maintain web-based q)pUcations. The IDE uses a Microsoft Management 
>^ Cmsole-style interlace in one embodiment \itd.th a tree view representing the form 
applications^ queries^ regular expressions and eAgents. 
5 a) AnAttecture 

Hie IDE ardiitecture is unique. 

i) The User Interface configuration for individual users is stored in an XML 
file. This information specifies which parts of the IDE to load at run dme (for 
example, the configuration file can specify that only the Forms designer part of 

10 die IDE should be loaded, and leaving the Regular E3q)res^on, Queries, and 

eAgent sections out of the IDE for that user. 

ii) Substantially only Form schema is stored in a unique XML file 

• Sq>arating these form schema files firom template files makes applications 
far more maintainable^ * 
IS • . Tte design stores substantially only the metadata/schema in the XML file 

used to rqiresrat the form. The presentation data is separately stored in a 
combination of CSS (cascading style sheet)^ XSL» and ASP files. ASP 
files are used to store the 'templates' of one or more forms, and tiiese 
templates form the surrounding gr^hical presentation of the form. To 
20 rq>resent die form fields, CSS files and XSL files are used to convert the 

XML metadata to HTML for presentation. The advantage of this is that 
it is very ea^ to change the entire look and feel of a form. This can be 
done without touching the XML metadata file, 
b) Graphic User Interface 
25 i) The IDE runs over die web or a network - i.e. users can develop forms 

remotely. 

ii) The IDE determines which components of the IDE should be loaded at 
runtime. This is based on an XML configuration file. This allows for different versions 
of the IDE to be created and deployed very easily. It also allows organizations to give 
30 some people access to only some aq>ects of the IDE. $ome of these versions may not 
include parts of the IDE - for example, the followmg can be included or excluded: 

• Forms (the Forms designer) 

• Regular E]q)ressions (validation code) 
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• Queries (database select queries used to populate form lists) 

• Actions (eAgent actions such as emailing fonn data and inserting data into 
the database 

• Action Queries (database action queries such as insert, update and delete) 
to be used from the Actions/eAgent section 

iii) A method is provided to create a form using a hierarchy of icons with 
attributes. 

Each form/^plication is represented as an icon with attributes. The 
attributes allow the user to q>ecify the following: 

• Where to store the form on the server 

• What to name the form 

• What caption the fiDrm should have 

• Which page to submit the form data to. 

• Whidi graphical template to use when displaying the form. 

• Help text to ^ear on the form. 

• Each form page is represented as an icon one level below the form icon in 
the IDE tree view. Hie page attributes allow the user to specify the 
following: 

• . The name and caption of the page 

• The order of the page (1* in the list, etc.) with respect to other 
pages in the form application 

• Help text to appear on diis page. 

• Each page section is represented as an icon under the page icon. The 
section attributes allow die user to specify die following: 

• The name and caption of the section 

• The order of the section (1", 2"*, etc.) in the current page 

• The help t»t to appear on this section 

• Section level validation. 

• Each section element is represented as an icon under the section icon. The 
section element attritnites allow the user to specify the following: 

• tiie location of tiie element within die section 

♦ element*s name and caption 
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a valid example of what a user can fill in for this element 
the maximum length of this element 
whether diis element has a list or not 
a defiiult value for this element 
help text for this element 

whether the element is required (must the user complete this 

elanent in order to submit the fomi?) 

the data type of the element (int, float* etc.) 

The c^italization of the element value (all upper case, all lower 

case, proper case) 

the minimum and maximum values for this element 

the name of the Regular Esqpression used to validate user input 

Also, Regular Bipressions are kept in separate XML ' 

metadata/schema files. However, during' form creaticm, the actual 

regular esqyression is inserted into the form metadata/schema. 

Simple ccmiparison validation to other fields 

Advanced comparison using ECMAScript (JavaScript) 

if the control used for this form is a list, whether the list comes 

form the database or not 

if the list comes bom the database, the name of the query used, 
database queries are used to pcpu\att dynamic pull-down menu 
choices on die fonn. The database queries are stored in tbie 
metadata/schema diat des^ibes the form. Database queries are 
defined in a sqiarate section of the IDE and stored in sq>arate 
XML files. 

database queries can be pre-processed (run at (tesign time) - i.e. 
the results stored in the metadata/schema document that describes 
the form. 

The control type used for this element 

If the list is nc^ populated from the datalxise, the list values to be 
used for this list 
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Whether the control used for ibis element should be displayed on a 
new row or not. 

The width of the control used to di^Iay the element 
Whether the control used should wrap to the next line 
The type of control which should be used 
If the control is a list, whether the list should be multiselect 
If the control is a list, the prompt to use in the list 
If the control is a text area, tfie number of rows and columns to be 
used. 

10 iy) A method is provided to publish forms to the w^b using a wizard which 

lists predefined templates and allows a user to select a template for the form, as well as a 
folder location for the form. Hie basic task of the publishing wizard is to create ASP 
pages and associated files in a publi^iing folder that associates/links a form schema with a 
template. Template files may have custom parameters/questions that are displayed inside 

IS the publishing wizard which allows for flexible on-the fly customization of templates just 
by answering the questions inside the publishing wizard. 

v) A meAod is provided to save, create, test and retrieve regular expressions 
using XML files for storage and retrieval. 

• Regular expressions are represented as icons in the GUI 

20 • Each. Regular Expression may be a set of ASCII characters that 

describes valid inputs 

• The IDE helps users create Regular Expressions 

• The IDE helps users test Regular Expressions 

« The IDE allows users to import Regular Expressions firom an outside 
25 data file 

• Tliis will allow the sales of Regular Expressions on the Web or 
network and their seamless incorporation into the IDE. 

vi) A method is provided to save, create and test database queries 

• * Database queries may be represented as icons in the GUI 

30 • Each Database Query is a custom SQL query that is able to mteract 

with relational databases. 
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• Database connecdans are described sq)arately - allowing the Database 
Query to be directed at multiple databases. (The database could be 
MS Access, MS SQL Server, Qraclei or other database ^ the user 
does iiot need to spedfy beforehand and can switch at any time 

5 without affecting the form.) 

• This gives users the ability to change the database used for a project 
without having to change the form metadata/schema at all. 

vii) A method i$ provided to store and retrieve form elements and form 
sections b a litvary. For example: 
10 •A Library of Sections and Fields 

•• A libniry from which users can drag and drop form sections and form 
fields into the form diey are currendy creating 

• LINKED sections and fields will retain die properties described in the 
library - thai, to make a universal change to a field common to many 

15 forms, one change m the library will be reflected in^ all forms. This 

provides the ability to make a change to a section or form that 
(qpti<mally) autonuvdcally changes all related ^plications in the users* 
web site. 

• CX>PIED secdons and fields will ix>t retain the properties described in 
20 the library and are customizable for each form. Subsequent changes 

in the library (such as q>ecifying a different database source) will not 
be reflected in all forms, but only forms that are linked to the library. 
Users can add any section, or field to the iite^ at any tixnt. 
2) Xnveatioii Runtime EnTironmoit 

25 

The Invention Runtime Environment is a highly scalable, maintainable, and reliable 
runtime environment that uses data cheated using the IDE or by other means to «rve 
sophisticated web based applications to users with bodi XMIxx)mpatible and non-XML* 
compatible browsers. 
30 a) Runtime EDviromncnt Architecture 

The Invention runtune ravironment is unique and includes a variety of aspects 
including: 
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i) A method tt> serve two or more distinct versions of the form/^plication 
using only one form/applicadon description file. 

• In one a^ect^ the design automatically creates and maintains two 
versions of each applicadon using only one form in the IDE. This 
S ' means that users of die IDE need only maintain one version of the 

form/application, but: 

• users of XML-compadble browsers are served a quick, 
efficient » dient-side version of the form, which reduces web 
server load and iticreases client-side performance. This 

10 version includes sending die schema XML file, and any XSL 

files, CSS files, and JavaScript files for navigation and 
validadon to the browser for processing. 

• Users of non-XMLKX)mpatible browsers are served a pure 
HTML/CSS version of the form pages which processes each 

IS page in the form on the server. Hiis version involves 

processing the XML sdiema file, and any XSL. files, 
JavaScript files and COM components on the server, and 
sending html and CSS to the browser. 

A mediod is provided (folder architecture) to store web files for. uldmate ease of 
maintainability and reuse of applicadon. An important aspect is the fiict diat die final 
form files can have mmimal size (less dian 10 lines) because of die fact that they only 
have the values diat differmtiate them from other forms and LINKS to both a form 
schema and a template. What makes diis possibly is the combination of a standardized 
folder structure with Server-Side Includes (SSI) diat use absolute paths. SSI are a 
programmatic construct of Active Server Pages that allow the inclusion of content ^m 
anodier file into die existing file at die server. The advantage of this approach is the 
ability to change bodi die schema and die lodk and feel ind^ndendy both at the time of 
Creadon and after the form has been published. Hiere is no need to republish the form 
for diese changes take effect; they take immediate effect Also, there is a n:m 
relationship between a template and a schema, i.e., one template can be used widi 
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XDult^le schemas and ottt schema can be used widi multiple templates. This allows for 
maximum reuse. 

A ccHnpany can have a standardized look and feel defined for all its forms or a subset of 
diem, and easily associate scbemas with this texnplate. If the company wishes to change 
S Ae standardi2ed look and feel, e^g., the name and logo of the company changed, the 
change has to be done only in the template and takes immediate effect for all the forms 
diat are associated with this template. 
Reuse of scbanas: 

10 An ^plication service provider (ASP), in one aspect, may develop and sell a set of 
standardized schemas for work processes. Several companies/customers may wish to use 
tfiese standardized schemas, however they may wish to have their own look and feel with 
the schemas. The ASP provides customized templates for each customer, and associates 
the resulting forms with the customized templates and the standard schemas. If there is a 

IS need to change the schema, e.g., another field is required, then the ASP only needs to 
change the standardized schema and die change takes immediate effect for all forms that 
link to this standardized schema. 
eAgoit Architecture 

20 A further aq>ect of the invention is the eAgent architecture. It uses a set of COM 
components and configurable XML files in a preferred embodiment to determine 
apprq>riate actions, and to perform these actions for each XML document received in the 
queue system. Some of the important aq>ects include; 

i) Pattern-content based selection of actions to be performed - an eAgent 
25 manager determines which Acticmset to perform by searching each incoming XML 

document for previously cadied XSL patterns. Using XSL patterns, a component (die 
eAgent Manager) determines the type of each incoming XML document, and determines 
which Actionset to perform, based on the type of XML document involved. The 
component knows which patterns to search for based on die cached XML selector 
30 documents. 

ii) A bot-pluggable eAgent component archltecmre: An architecture in which 
'action' components can be added without having to recompile any code, stop and restart 
any services, or interrupt the functionality in any way. More eAgents (with corresponding 
action files) can be added to the system at any time widiout interruption. All that is 
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needed is that any Actionset file which will utilize the new eAgent be updated with the 
new ProgID of the eAgent, and which actions to perform* Since Acdonset files are XML 
documents, this does not require the stopping and starting or recompiling of any code or 
code components. 

iii) A business rules system which is changeable at run-time (without 
interrupting normal q>eradon) - the eAgent architecture includes several components that 
implement the system, business rules or work flow. These are the eAgent Manager^ the 
eAgent Acdon Coordinator, and the eAgents, in a dered architecture. However, the 
business rules themselves are defined in XML documents which can be changed without 
recompiling any code, and in &ct can be changed during run-time. (Prior art systems 
^ically would at the very least require die system to l>e stopped and restarted, and m 
many cases a complete recompile of the code wcMild be required). 

iv) A decoupled action set system: The eAgents in the system are self aware . 
ojily. They are not aware of the existrace in the system of other eAgents. De^ite this, 
actions can be performed which transfer information from one eAgent to another. This is 
done as follows: 

The eAgent Action Coordinator calls an eAgent function and passes the 
eAgent a copy of the routing document,, which incorporates both the 
incommg XML document and the results of execution from, previous 
eAgents. It receives back the result of the processing as an XML 
document/element, which it adds to a rwting document attached to the 
original XML document, before passing the original XML document and 
the routing document to the next eAgent specified in die Actionset. 
Another advantage of Uiis is that there is no possibility for an eAgent to 
corrupt the original message. But more unportandy, eAgents need not be 
. designed to work in tandem with any other code or components other than 
the eAgent Acticm Coordinator. . 

Specific eA^ts 

The current implementation of die invration employs several eAgents: 
Action-Query eAgent: 

The Action*Query eAgent allows the system to insert, update and delete 
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data in any ODBC aQd/or OLE OB compatibte database. The data from the 
incoming XML document can be mapped to fields in die database tables. 
The mapping is defined in Action-Query documents and the eAgent uses 
this and the incoming XML document to insert, update and/or delete data 
in the database. 

SdimaeAgem: 

The scbma eAgent allows the system to automadcally create and update 
database tables and action queries based on die incoming XML document* 
Udng this automation facility radically simplifies the development of XML 
to database mq^ing. 

PDFeAgem: 

The PDF eAgent peculates an empty PDF form template widi data from 
the incoming XML document The PDF eAgent action document defines 
the template to use and other relevant parameters. A naming convention is 
used to map the information from the incoming XML document to the 
fields inside the PDF form template. 

eMail eAgent: 

The eMail eAgent allows the system to send eMails to multiple recipients 
with a subject, a body, and' zero or more attachments. The eMail eAgent 
action document constitutes the template for the eMail, and is used in 
coordination with the incoming XML document to construct the eMail. 

c 

Script eAgent: 

The script eAgent allows an ActiveScript, such as one written in VBScript, 
JavaScript or Perl, to perform any action on the incoming XML document 
As these scripts have access to COM components on die system, inchiding 
the database, file system, eMail and other components* these scripts offer 
an enormous amount of flexibility. The access to the incoming XML 
document is simplified by providing an object model for the script to use. 



-54. 



wo 01/37170 



PCTAJSOO/31221 



Sample workflow (simplifSedt); 
Business Task . 

The time for processing of ^request for Jeave" forms must be improved. 
The HR manager wants to be inmiediately notified of new requests for 
leave* S/be also wants a database of all requests so s/be can view leave- 
related reports. In addition, due to company policies, s/he also needs the 
requests in writing, signed by the person requesting the leave. Ideally, the 
data should only be entered once. 

Techmcal Implementation 

The form "Request For Leave** is filled out in the browser by the person 
requesting die leave. When the user submits his/her request the request for 
leave ^plicadon (XML document) is submitted to a queue. The queue 
manager 42 picks it up from the queue and passes it on to the eAgent 
manager 44, which determines the corresponding Acticxiset. The Acdonset 
encompass&s four actions: 

The first action is passed to the Acdon-Query eAgent with the document 
ID of "insertLeave". The Acdon-Query eAgent reads the action document 
and then inserts the relevant data from the XML document into the 
database and returns execution to the eAgent Action Coordinator 46, 
indicating diat it has successfully completed it*s task. In this way, all 
requests, are recorded in a database which can be utilized for analysis and 
reporting purposes. 

The eAgent Action Coordinator 46 then calls the PDF eAgent with the 
"leave" action ID. The PDF eAgent reads the action document, finds the 
location and parameters of the PDF form template and using a naming 
conventicm, fills all fields in the template with the corresponding parts of 
the XML document and saves the resulting PDF document. In addition to 
returning a success code, it documents the location of this PDF document 
in the routing document for later use. 



-55- 



wo 01/37170 



PCTaJSOO/31221 



The third action involves sending the person who submitted the leave 
request an eMail with the PDF document as an attachment that was created 
in the previous action. For this the eMail eA^nt is called with the 
*leaveAck'' action document ID* The eMail eAgent loads this action 
document and constructs an eMail, which contains the person who 
submitted the leave request as a recipient and contains the PDF fonn as an 
attachment. The eMail eAgent then sends this eMail to the person 
requesting the leave. To fulfill the current company regulations, that 
person can then print out the PDF fonn» dgn it and pass it on to the HR 
department There is no need to enter the data a second time. The eAgent 
returns a success code to tiie eAgent Action coordinator 46. 

The fourth action involves sendmg the HR manager an eMail. The eMail 
eAgent is called by the eAgent Action Coordinator 46 witih the *'leaveHR" 
action document ID. The eMail eAgent reads the action document and 
IS constructs and sends the eMail to the HR manager. 

Additional e^mmeice aspects 

Faced with today*s new, rapidly expanding marketplace, e-commerce merchants 
have found themselves unable to ef6ciendy and effectively communicate their orders to 
suppliei^ and unable to obtain vital business process info^rmation, such as real*time 

20 inventory levels* Up until now, it has been extremely difficult for companies to conduct 
business over the Internet because of the lack of a single technical vocabulary for 
describing business processes. 

The only widely adopted e-oommerce transacti<xi sohition today. Electronic Data 
Interchange (EDI), has fostered a fragmrated market, where trading parmers have created 

25 ''islands of standardization'' which support only specific vendors and implementations. 
Each interconnection must be carefully mapped from a source system to the receiving 
system and maintained individuaUy as source and receivmg systems evolve. Each new 
trading panno- adds to die staggering number of unique combinations which must be 
individually structured and maintained— resulting in global technical gridlock. 

30 EDrs high costs, low ROI and limi^ services have restricted its market 

penetration to less than 2% of all US businesses. 
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Online Transactioii QearingJioQse Solution 

The eAgent tiered configuration, described as one aspect of the present Invention, 
possesses the unique c^ability to provide an unlimited volume and variety of lowest-cost 
transactions between any vendor and any supplier, tiu-ough an online transaction 
S clearinghouse. 

Based on open Internet technologies and standards, including XML, this aspect of 
the present invention fulfills a ^ecific niche thai has not, until now, been successfully 
. addressed. Using, multiple, geographically-dispersed high-capacity servers, this aspect of 
the invention allows the receipt and processing of intelligent business-to-business (b2b) 
10 transaction and workflow instructions, including purchase orders, payment and fulfilhnent 
instructions, and price and inventory requests. 

This aspect of the present invention &cilitates seamlessly integrating all 
transactions, and will guarantee the distribution of correct transaction instructions, 
regardless of the ERP systems, legacy systems, or databases used by suppliers and 
IS merdiants involved in the transacticm. The online transaction clearinghouse facilitated by 
the present invention is a conq>lete supply-side transaction solution designed to maximize 
accessibility, reiiabiliQ?, responsive service and speed of fulfillment. 

Eadi transaction in accordance with this aspect of the present invention relies on 
the following services, each of which may be contained within the Fonns Web site: 

20 L Hie Guaranteed Transaction. E*commerce Web sites and/or Forms web sites will 
send secure, XML-formaned transactions to a global array of Message Queue (MQ) 
Servers, all poised to capture each e<^mmerce transaction and forward it to the 
closest facility. If one MQ Server goes off-line, any of the others will step in to 
seamlessly take its place. 

25 2. Tlie Business Rules Package. The E-commerce Web site* tnmsaction instructions 
and Forms environment will contain business rules, in addition to the basic transaction 
that will be executed using tiie described eAgent workflow engine. 
TlieeAgent. 

This aspect of the Inventira will use the eAgent architecture to transfer orders and 
30 data requests (such as staois of order) to a merchant's back-end system and receive 
information, as apprc^riate. 
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This e-omunerce aspect of the present Invention is the only solution to fully 
address aJl four m^or sources of transaction costs: 

1 . The asynchronous systems architecture and intelligent eAgent technology of this e- 
commerce aspect of the invention together provide an unlimited capacity to 

5 receive, store and process information. This uiil^ie combination of capalnlities 

engenders near-zero marginal quantitative and qualitative costs of new transactions. 

2. This e-commerce aspect of the Inventicm assures transaction reliatulity* oxf-time 
payment and low charge-back rates* 

3. This e-conmierce aspect of die present mvention provides timely market 
10 intelligence and an online adjustable 'smart' bu^ness logic vehicle^ which combine 

to enable instant reactions to market fluctuations. 
4« litis e-commerce a^>ect of the present Invention drives transaction services and 

buyer-supplier relationships toward perfect competition, continually reducing the 

'asset specificity* portion of the transaction cost* 
IS This e-commeice aspect of the Inventira enables enterprises to create a universally 

accessible value web of increasingly complex, interlocking products and cross-selling 
arraiigements. 

From the above, it can be seen that important aspects of die present invention 
include: 

20 • Use of a tiered software architerfiire diat does not compromise on 

scalability, maintainabiliiy and performance. 

• Ease of integratfon: The present invention offers exceptional ability to 
integrate the submitted form data with any other computer system or user 
by having schema and captured daia as an XNfL document. 

25 m Usesonem^datadescriptionof forms to display multiple outputs (client-. 

side DHTML/XML/XSL, or server-side Active Server Pages (ASP), or 
many other possibilities*) 

• Simplicity. A forms designer needs to only be able to use one simple 
graphical user interface to create, admmister and publish powerful forms to 

30 die Intranet/Internet without the need to have any know-how in the areas of 

HTML/ASP/XML/XSL/CSS/Regular Expressions/JavaScript etc. 
Using this innovative approach, the present Invention can be developed and 
deployed by non-programmers in a short period of time, and over the Internet or over a 
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network. Changes to forms (maintenance) can be made even more quickly than form 
creation (again over the Internet). The present inventioa supports all of the major 
browsers and is highly scalable, fosi and maintainable. And» by having the submitted 
data available as XML, the results can be easily integrated into any other system. Befdre 
5 ' the present invention, developing online forms with fields, validation, a preview page, 
and separate versions for lES.O and Netscs^ would have taken a fully qualified 
programmer several weeks. Maintaining such an ^plicatim would have taken the same 
programmer far bnger. 

The foregoing description of the preferred embodiment of the Invention has been 

10 presmted for purpose of illustration and description. It is not intended to be exhaustive 
or to limit the Invention to the precise form disclosed, and modifications and variations 
are possible in light of the above teachings or may be acquired from practice of the 
invention. Tb^ embodiments were diosen in order to explain the principles of the 
Invention and its practical {^plications in order to enable one skilled in the art to utilize 

IS the Invention in varicms embodiments and with various modifications as are suited to die 
particular use contemplated. It is intended that the scqie of the Invention be defined by 
the claims sqypended hereto, and their equivalents. 
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WE CLAIM: 

L An mtegrated development method for creating forms, comprising the 
steps of: 

storing at least erne schema for a form m a first file at a computing resource^ 
wherein said schema comprises minima] user interface representations; 

accessing at least one template of a form in at least one second file separate fiom 
said first file, wherein each of said templates comprises a user tnterfiace rq)resratation of 
said form; ' 

selecting one of said at least one template and one of said at least one scbma; and 

creating at least one linking file that links said sdected schema and said selected 
template. 

2. A m^hod as defined in cdaim 1, wherein said schema storing step 
comprises the step of storing a plurality of different sdienuu 

3. A method as defined m claim 1, wherein a plurality of different templates 
can be accessed in said traiplate accessing stq>. 

4. . A method as defined in claim 1. wherein said schema storing step 
comprises the step of storing a plurality of different schema* 

5. A method as defined in claim 1, wherein said schema storing step 
comprises creating said scbetna, including the step of copying at least one element from a 
different schema mto said sdiema being created. 

6. A method as defined in claim 1« wherein said schema storing step 
comprises the step of copying at least one element from a database of reusable elements to 
form said schema. 

7. A method as defined m claim 1, wherein said sch^a storing step 
comprises the step of linking at least one element into said schema from a database of 
reusable elments. 

8. A method as defined in claim 7, wherein said reusable elemmts are fields. 
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9. A method as defined in claim 7 wherein said reusable elements is a 
phirality of said fields. 

10. A method as defined in claim 7, wherein said reusable elements are 
queries. 

1 L A method as defined in claim 1» further comprising the step of 

creating said schema, including the steps of selecting query information from a 

query information database separate from said first and second files, and mcorporating 

said query inifonnation into said schema. 

12. A method as defined in claim II, wherein said query information is linked 
to said schema. 

13. A method as defmed in claim 1, further comprismg the step of: 

creating said schema, including the steps of selecting a regular expression from a 
regular expression database separate from said first and second files, and incorporating 
said regular expression into said schema so as to validate inputted data. 

14. A method as defined in claim 13, wherein said selected regular expression 
is linked into said schema. 

15. A method as defined in claim 1, further comprising the step of creating 
said schema, including the stq>s of selecting a user*defihed control from a custom 
database separate from said first and second files, incorporating said user-defined control 
into said schema so as to provide improved input for fields made up of a plurality of 
variable and fixed text elraients. 

16. A method as defined in claim 1, wherein said schema storing step 
comprises the step of storing said schema in a data-centric hierarchical .storage and 
retrieval mechanism. 

17. A method as defined in claun 16, wherein said data-centric hierarchical 
storage and retrieval mechanism is XML. 

18. A method as defined in claim 1; further comprising the steps of at runtime 
converting said schema to an interface with a user. 
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19. A method as defined in claim 18« wherein said converting step ccnspiises 
converting die schema to HTML. 



20. A method as defined in claim 15, wherein said schema includes elements 
with attributes. 

21. A method as <tefiiied m claim 20, fiirdier comprising the step at runtime of 
using attribute based validation to validate end user input data. 

22. A method as defined in claim 21, furdier comprising the step at runtime if 
an error is discovered during said validation stq), mcluding an error flag and an 
associated error message in said schema or separate schema in said data-centric 
hierarchical storage and retrieval mechanism. 

23. A method as defined in claim 22 » wherdn said error message is presented 
to a user. 

24. A method as defined in claim 1, further comprising the stq> of: allowing 
the separate creatioa and modification of parts of the fonns creation and maintenance 
process and thereby allowing specialuation of tasks. 

25. A method as defined in claim 24» wherein said tasks include designing 
quenes, regoiar expressions, ^ser-defmed contrdls, templates and forms cr^on and. 
processing of die submitted of data. 

26. A method as defined id claim 1, wherem said schema comprises at least 
one field; and 

further compri^ng a field library separate fnxn said first and second files for 
storing one or more fields; and 

wherein said schema storing 5tq> comprises the steps of: 

storing in a file a schema ccmiprising a Imk to said at least one field in said field 
library; and 

storing in a file a transformed schema that does not include said link to said at 
least one field, but rather contents of that field 
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27, A method as defined in claim 26, wherein said schema inchides a plurality 
of said fields, and wherem said schema mchides links to at least two different fields in 
said field library* 

28. A method as defined in claim 26, wherein for a field that is changed in said 
field library, updating a phirality of said schema that contain a link to said changed field. 

29.. A method as defined in claim 28» wherein said updating step mcludes the 
steps of retransforming said schema. 

30. A method, as defined in claim 28, wherein said updating step comprises 
performing said updadng step during runtime. 

3L A method as defined in claim 1, wherein said linking, file creating step 
comprises die stq>s of creating a linking file for a data-centric hierarchical storage and 
retrieval mechanism user-interface program, and creating a linking file for a non*data 
centric hierarchical storage and retrieval medbanism raabled user-interface program* 

32. A method as defined in claun 1, wherein a navigation engine can navigate 
among a plurality of sections, and wherein said scherna stormg step comprises a step of 
storing a schema with at least two sections. 

33. A method as defined in claim 1, further comprising the step of defining 
template q>ecific customization questions* 

34. A method as defined in claim 1, wherein said schema comprises at least 
one field; and further onnprising the step of creating a schema and storing ;i schema 
including a link from said one field to a field in said field library of reusable fields; and 
storing a transformed schema with no links. 

35. A method as defined in claim 1, if a user interface program is not 
compatible with a data-centric hierarchical storage and retrieval mechanism, then creating 
a unique idendfier at runtime for an instance of one said storage schemas. 

36. , A method as defined in claim 35, wherein said unique identifier is passed . 
between a navigation engine in said computing resource to and from a user interface 
program at a user location. 
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37. A mediod as defmed in claim 1, wherein at runtime submitted end user 
data is written to a queue. 

38. A method as defined in claim 37, wherein a log of transactions is created 
for said queue. 

39« A method as defined in claim 1, wherein for a user interface program that 
is compatible with a data centric hieiarchical storage and retrieval mechanism, at runtime 
selecting a schema and sending said selected schema to said user interfiux program as an 
island of data in accordance with said dataKrentric hierardiical storage and retrieval 
mechanism, within a form page in presentation language. 

40. A method as defined in daim 39, wherem said selected schema is in the 
form of an XML island in an HTML page. 

4L A method to publish forms comprismg the steps of: 
creating a schema; 

providing a list of predefined templates; 
selecting a template; 
selecting a publishing destination; and 
linking said schema to said selected template. 

42* A method as defined in claim 41 « further comprising the st^ of responding 
to template spedfic customizadon questions and linking responses to said selected 
template. 

43. A method for creating a regular expres^on file compri^ng the steps of: 
inputting and presenting a name for a regular expression; 
inputting and presenting a pattern for a regular expression that is to be used in a 
validation engine; . 

inputting and presenting an error message for user inputs tiiat do not match said 
pattern; 

inputting at least one test case; and 

comparing said test case to said pattern; and 

presenting a message in req>onse to said comparison step. 
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44. A method as defined in claim 43, further including the step of inputting 
and presenting a description of said regular expression. 

45. A method as defined in claim 43, further comprising the step of inputting 
and presenting at least one valid example of said pattern. 

46. A navigation engine program product, comprising: . 

a computer usable medium having i:^mputer readable program code embodied 
therein comprising: 

first code, for transforming data-centric hierarchical storage and retrieval 
mechanism data to presentation language; 

second code for. r«:eivmg data in presentation language and converting said 
received data to said data-centric hierarchic^ storage and retrieval mechanism; 

third code for performing attribute based validation on said data; 

fourth code for providing navigation among present pages; and 

fif% code for saving said data in response to a command. 

47. A computer program product as defined in claim 46, wherein said third 
code operates to perform said attribute validation only after said data has been converted 
to said data-centric hierarchical storage and retrieval mechanism by said second code, 

48. A method for processing forms on a u$er-interface program, comprising 
thest^sof 

receiving an engine and a file with a form including a sch^a and a template in 
data-centric hierarchical storage and retrieval mechanism; 

transforming with said engine said form from said data-centric hierarchical storage 
and retrieval mechanism into presentation language and presentiing said form at said user- 
inter£ace program; 

receiving user hiput data in said presentation language; 

converting said user mput data to said data-centric hierarchical storage and 
retrieval mechanism; 

performing attribute based validation on said converted user input data; 

incorporating any error detected in said validation st^ in. said data-centric 
hierarchical storage and retrieval mechanism into said form schema or separate form 
schema; 
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converting said any error into presentation language and presenting an error 
message associated therewilb to said user; 

allowing said user to correct said user input data, if necessary; and 
saving said user input data. 

49. A method as defined in claim 48. wherein said form transforming step 
comprises the step of recdving a schema as an island in the format of a data centric 
hierarchical storage and retrieval mechanism in a form page represented m presentation 
language. 

50. A method as defined in claim 49, wherein said schema is stored as an 
XML island in an HTML page. 

SL A mediod as defined in 48* iiirther comprising the step of presenting a 
preview of s^d form to said user with said user 'mpxxt data incorporated therein. 

52. A method as defined in claim 48, ftmher ccHnprising the step of allowing 
said user to navigate among diffeient sections in said form. 

53. A method as defined in c^m 48, further comprising the step of submitting 
user data and writing said submitted user data to a queue. 

54. A method as defined in claim 53, further comprising the svsp of creating a 
log of transactions of said schema. 

55. A runtime envircmment method for an electronic forms applications* 
comprising the steps of: 

receiving a forms request from a user-interface program; 

determining if said user-interfatce program is compatible or not compatible with a 
data-centric hierarchical storage and retrieval mechanism; 

sending from a c(Hnputing rescnirce to said user-interfiace program, if said user- 
interface program is ccxnpatible with said language, a schema file containing form 
information to be inserted into a form template and a form navigation engine and a form 
input validaticm engine; and 

if said user-interfiice program is not compatible with said storage and retrieval 
mechanism, sending user input information to said computing resource for processing and 
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sending a presentation langua^ version of form pages resulting from said computing 
resource processing hack to said user^nterfiace program. 

56. A method as defined in claim 55, wherein at runtime the stq> is performed 
of using attributes to validate end user input data. 

57. A method as defined in claim 55, where at runtime the step is performed of 
writing results of said validation and any error messagie associated tiierewith into said 
schema. 

58. A method as defined in claim 55^ if a user inter£ace program is not 
compatible with said data-centric hierarchical storage and retrieval mechanism, then 
creating a unique identifier at runtime for forms processed at said computing resource. 

59. A method as defined in claim 55, wherein said unique identifier is passed 
between a navigation engine in said computing resource to and from said user interface 
program at a user location. 

60. A mediod as defined in claim 55, wherein at runtime submitted end user 
data is written to a queue. 

61. A method as defined in claim 60, wherein a log of. transactions is created 
for said qu^e. 

62. A method as defined in claim 55, wherein for a user interface program that 
is compatible with a data^ntric hierarchical storage and retrieval mechanism, at runtime 
selecting a schema and sending said selected schema to said user interface program as an 
island of data in accordance with said data-centric , hierarchical storage and retrieval 
mechanism, widiin a form page in presentation language. 

63. A method as defined in claim 62; wherein said selected sdiema is in the 
form of an XML island in an HTML page. 

64. A method for creating a form file comprising the steps of: 
storing in a form file a path to a schema in a first file at a storage location; 

. storing in said form file a path to a template in a second file different from said 
first file at a storage location; and 
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Storing said fonn file at a user location* 

65. A method as defined in claim 64, wherein said stq> of storing said fonn 
file includes the step of storing customizadra information for a template. 

66. A method as defined in claim 64, wherein storing said form file step 
inchides the step of storing customization information for a form. 

67. A method as defined in claim 64, wherein said stored paths are absolute 

paths. 

6S. A method for perfcHming customized actions in a computing envtrooment, 
comprising the stqps of: 

providing at least one selector file, each selector file containing at least one 
selector pattern and associated with an actionset that contains at least one action, wherein 
. s^d at lea&t one action contains ^t least an eAgent ID and an associated action document 
ID; 

obtaining a document for processing from a queue; 

searching said documrat for a match to at least one of said selector patterns of said 
selector files; 

if a match is found for one of said selector patterns, executing said at least one 
acdtm in said Acticmscft assooaAed wiih s^d matched selector ii\c, mcluf&ig loa^g an 
eAgat ^)ecified by said eAgent ID; and 

said eAgent reading an action document specified by said associated action 
document ID and performing an action specified therein. 

69. A method as defined in daim 68, fiirtb^ comprismg the step of obtaining a 
document for processing from one of a plurality of said queues. 

70. A method as defined in claim 68, fiirther comprising the steps of: creating 
a routing document; attaching said document to said routing document; and attaching 
information to said routing document 

7L A method as defined in claim 70, wherein said information attached to said 
renting document relates to a status of the action. 
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72. A method as defined in claim 70, wherein said information attached to said 
roating document comprises result information from said action performed by ^d 
eAgent. 

73. A method as defined in claim 72, wherein said information is readable by a 
different eAgent* 

74. A method as defined in claim 70, wherein said information attaching step 
comprises attaching said information only from non-eAgents. 

75. A niethod as defined in claim 68, wherein said document is in a format of 
a data-centric hierarchical storage and retrieval mechanism, 

76. A method as defined in claim 68, wberem said document is in XML* 

77. A method as defined m claim 68, wherein said selector file, routing 
(tocument, Actionset and action documents are jn a format of a data-cmtric hierarchical 
storage and retrieval mechanian. 

78. A method as defined in claim 68, wherem said selector file, routing 
document; Actionset and action documents are in XML^ 

79. A method as defined in claim 70, wherem said information attached to said 
document comprises ah indication of stams of sa|d action by said eAgent. 

80. A method as defined in claim 68, further comprising die stq> of creating a 
completion file, wherein said routmg documrat is stored in die format of a data-centric 
hierarchical storage and retrieval mechanism. 

8L A method as defined in claim 80, wherein said completion file is stored to 
a queue. 

82. A method as defined in claim 70, wherem said information attached to said 
routing document comprises a time stamp of at least when the action was completed. 

83. A method as defined in claim 70, further comprising the step of 
determining if a second action is present with an associated second document ID and a 
second eAgent ID; 
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said eAgent associated with said second eA^t ID reading an action document 
specified by said second action document ID and performing an action specified dierein; 
attaching information to said routing document; and 

sending said routing document with, said attached information to said completion 

file. 

84. A method as defined in daim 70, further ccmiprising the step of 
determining if a match to a second selector pattern in said selector files is found* and if 
said match to said second selector file is found, executing a second Acdonset associated 
widi said matched second selector file, inchiding loading an eAgent specified by an 
eAgent ID in said second Actions^; . 

said eAgent reading an acticm document associated with an acticm document ID m 
said second acdon set and performing an action specified dierein; and 
attachmg information to said document 

85. A method as defined in claim 68, wherein said Actionset contains another 
Actionset. 

86. A method as defined in claim 68, wherein said Acdonset contains at least 
<Hie command from a set of conmiands comprising branching and rq)etition commands. 

87. A mediod as defined in claim 68, wherein said Actionset contains a parallel 
execution command. 

88. A method as defined in claim 68, wherein said Actionset contains a time 
controljed execution command. 

89. A meduxl as defined in claim 68, wfaerem said providing step includes 
providing a plurality of selector files, wiA each of said selector files containing a priority 
relative to other sdector files. 

90. A system for generating forms in a computing environment, comprising: 
a schema database; 

a template database separate from said schema database; and 
at least one Imkage file, each containing code to link a selected schema with a 
selected template. 
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91. A system as defined in claim 90, further comprising : a database of 
validation patterns sq>antte from said schema database and said template database; and a 
database of query information separate from said schema database and said template 
database 

92. A system as defined in claim 91, further comprising a plurality of different 
forms Creadon modules, with each of said modules providing a different method of 
manipulating one or mor? of said databases. 

93. A system as defined in claim 91, further comprising a forms designer, 
configuration database listing which of said modules are to be used by different forms 
designers at runtime. 

94. A system as defined in clahn 92, wherein said plurali^ of modules 
includes a forms creation modules for allowing a forms designer to create a schema widi 
validation. 

95. A ^stem as defined in claim 92 wherein said phirality of modules includes 
a forms creation module for allowing a forms designer to select regular expressions from 
said regular expression database for use in said validation. 

96. A system as defined in claim 94, wherein said forms creation modules 
inchides code to provide a link in said schema to said selected regular expression in said 
regular expression database. 

97. A system as defined in claim 92, wherein plurality of modules includes: 

a forms creation module for allowing a forms designer to select query information ^ 
from said query mformation database to create elements in said schema. 

98. A system as defined in claim 97, wherem said query selecting forms 
creation module includes code to provide a link in a schema to said selected query 
information in said query database* 

99. A system as defined m claim 97, wherein said plurality of modules 
includes a regular expressions module for allowing said forms designer to add/change 
regular expressions in said regular expressions database. 
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100. A system as defined in claim 92, wherein said plurality of different forms 
creation modules includes a query information module for allowing said forms designer to 
add/change query information in said query information database. 

101. A system as defined in claim 90, furtiier ccmiprising an elements database 
for storing a plurality of differem elements that may be reused in forms. 

102* A system as defined in claim 92, further comprising an actions module for 
including code for controlling at least one tAgcAu 

103. A system as defined in claim 92, ftinher comprising a custom module for 
creation of user-defined controls. 

104. A system as defined in claim 92, wherein said phirali^ of modules 
includes a forms creation modules for allowing a forms designer to selea a user-defined 
control. 

105. A system for performing actions on documents in a computing 
environment, comprising: 

a selector file database containing a plurality of selector files; 
an Actionset database containing a plurality of Actionsets; 
wherein each selector file is associated with eicactly one Actionset; 
an eAgent spedfic action document database containing a plurality of action 
documents timt are specific to eAgents; 

wherein each of said Acticmsets is associated with at least one action document. 

106. A system as defined in claim 105, further comprising at least one creation 
module for creating and/or man^xil^g envies in (me of said databases. 

107. A system as defined in claim IQS, further comprising: 

code for specifying at least cme of said selector files from said selector file 
database; 

code for t^ifying at least one of said Actionsets from said Actionset database; 
code for specifying at least one of said eAgent specific action documents of said 
eAgent q>ecific action documents; 

code for linking said ^ecified selector file with said specified Actionset; and 

-72- 



BNSOOCID: <W0 



0137* 70A2 I > 



wo 01/37170 



PCTAJSOO/31221 



code for linking said specified Actionset mth said q)ecified action document 

108. A computer program product for an integrated devel€>pment environment^ 
comprising: 

a computer usable medium having a computer readable code embodied therein, 
comprising: 

presentation host code, said presentation host codc^ including shared user interface 
and lo^c code components, code for reading a IDE configuration, and code for loading 
any IDE component code and business logic components code as defined in said IDE 
configuration; 

at least one IDE component code loaded by said presentation host on said user- 
interface program, said IDE component code including a user interface; and 

at least one business logic component code loaded by said presentation host on said 
. user-interface program, said business logic component code defining the interrelationships 
between objects represented in said user interface. 

109* A computer program product as defined in 108, further including a. data 
access abstraction layer code that allows business components code to read and write 
information to/from a computing resource. 

110. A computer program product as defined in claim 108, wherein said 
presentation host code runs within a browser. 

111. A computer program product as defined in claim 109, wherein said data 
access layer access allows reading and writing informaticm to/from a computing resource 
over a communications link. 

112. A computer program product as defined in claim 109, wherein said data 
access layer access allows reading and writing information to/from a local computing 
resource. 

113. A computer program product as defined in claim 108, wherein said 
presentation host includes code for sharing business components code. 

114. A computer program product as defined in claim 108, wherein presentation 
host code, said IDE component code, said business component code, said data access 
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abstraction layer code are each on a different tier, wherein a der permits conununication 
only with ccMnponents in the same or neighboring tiers. 

1 IS* An integrated development environment method, comprising the steps of: ' 

loading onto a computer resource code in a tiered architecture ccNnprising: 

a presentation host tier that includes presentation host code, said presentatim host 

codQ including shared user bter&ce and logic code components, code for reading a IDE 

configuration, and code for loading any IDE component code and business logic 

components code as defined in said IDE configuration; 

an IDE componrat tier, including at least one IDE component code loaded by said 

presentation host on said user-interfeoe program, said IDE component code including a 

user interiiace; 

a business log^ craqxment tier, including at least one business logic component 
code loaded by said presentation host on said user-inter&ce program, said business logic 
component code defining the interrelationships between objects rq>resented in said user 
interface; 

a data access abstraction layer tier, including a data access abstraction layer cocte 
that allows business components code to read and write information to/ftom a computing 
resource; and 

communicating with a remote computing resource through use of said data access 
abstraction layer code. 

116. A method as defined in claim 115, wherein said communicating step 
includes the stq> of communicating over the Internet. 

117. A method as ^fined in claim 115, wherein said cbminunicattng step 
conq>rises the stq> of ccHnmunicating witii a remote data access tier in said computing 
resource, wherein said remote data access tier is a different tier from a data tier in said 
remote computing resource. 

118. A method as defined in claim 116, wherein said communicating step 
comprises the itsp of communicating with a remote data access tier in said computing 
resource, wherein said remote data access tier is a different tier from a data tier in said 
rmiote computing resource. 
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1 19. A computer program product comprising: 

a medium with machine-readable code stored thereon which gives the ability to its 
computer to perform form creation tasks, comprising:, 
first code for facilitating a schema database; 

second code for facilitatmg a template database separate from said schema 
database; 

third code for facilitating at least one luikage file, each contaming code to link a 
selected schema in said schema, database with a selected template in said template 
database; 

fourth code for fiEicilitating a database of validation patterns separate from said 
schema database and said template database; and 

fifth code for facilitating a database of query information separate frcmi said 
schema database and said template database. 

120* A computer program product as defined in claim 1 19, further comprising: 
a selector file database containing a phirality of selector files; 
an Actionset database containing a plurality of Actionsets; 
one or more eAgeat specific acdon document databases containing eAgent specific 
action documents; 

at least one module for creation and manipulation of said databases. 

121. A computer program product as defined in claim 119, further comprising 
code for a plurality of different forms creation modules, with each of said modules 
providing a different method of manipulating one or more of said databases; and a forms 
designer configuradon database listing which of said modules that are to be downloaded 
to different forms desigmrs at runtime. 

122. A computer program product as defined m claim 119, wherein said code 
for said phirality of modules includes: 

code for a forms creation modules for allowmg a forms designer to create a 
schema with validation,' and to select regular e;q>ressions from said regular expression 
database for use in said validation. 
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123. A compator program product as defined in claom 122, wherein said code 
for said forms creation modules includes code to provide a link in said schema to said 
selected regular expression in said regular expressi<m database* 

124. A computer program product as defined in claim 121, wherein said code 
for said phirality of modules inchides: 

code for a forms creation module for allowing a' forms designer to select query 
information firom said (piery information database to create elements in said schema, 

125. A computer program product as defined in claim 122, wherein said code 
for said fonns creation module inchjdes code to provide a Imk in a schema to said 
selected query information in said query database, 

126. A computer program product as defined, in claim 121, wherein said code 
for said plurality of modules includes a regular expressions module for allowing said 
forms designer to add/change regular expressions in said regular egressions database. 

127. A computer program product as defined in claim 121, wherein said code 
for said phjrality of modules includes a query infoxmaticm module for allowing said forms 
designer to add/change query information in said query information database. 

128. A ccxnpqter program procbict as defined in claim 119, fiirtter comprising 
code for facilitating an elemmts database for storing a plurality of cBfierent elonents that 
niay be reused in forms. 

129. A compute program product as defined in claim 119, further comprising 
cod& for facilitating an actions module for including code for controlling at least one 
eAgent. 

130. A computer program product as defined in claim 121, fortfaer comprising 
code for focilitating a custom module for creation of user-defined controls. 
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FORMS CREATION METHOD AND ^-COMMERCE METHOD 
BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present inventioii relates generally to forms creation software and e-commerce, and 
more particalarly, to a method, system and software for creating and maintaining highly 
scalable and fully functional, multi-step web-based forms and the creation of a multi-tiered e- 
commerce method and system. 

2. Description of the Related Art 

There is a specific problem with current forms development software in that they are 
not scalable, and are not easily in:q)lemented across different computer systems. Such prior art 
systems typically require experienced programmers to design the forms on those systems. 

There is also the problem of controlling the workflow in e-commerce operations, 
particularly those e-commerce operations using multiple components. 

These problems have not been solved in the prior art. 

SUMMARY OF THE INVENTION 

Briefly, in a first aspect the present invention comprises an integrated development 
method for creating forms, including the steps of: storing at least one schema for a form in a 
first file at a confuting resource, wherein the schema comprises minimal user interface 
representations; accessing at least one template of a form in at least one second file separate 
from the first file at a computing resource, wherein each of the templates coii5)rises a user 
interface representation of the form; selecting one of the at least one template and one of the at 
least one schema; and creating at least one linldng file that links the selected schema and the 
selected template. 

In a further aspect of the invention, a method is provided to publish forms conq>rising 
the steps of: creating a schema; providing a list of predefined tenq>lates; selecting a template; 
selecting a publishing destination; and linking the schema to the selected teniplate. 

In yet a flirther aspect of the present invention, a method is provided for creating a 
regular expression file comprising the steps of; inputting and presenting a name for a regular 
expression; inputting and presenting a pattern for a regular expression that is to be used m a 
validation engine; inputting and presenting an error message for user inputs that do n6t match 
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the pattern; iiqnittmg at least one test case; and comparmg the test case to the pattern; aiKl 
presenting a message in response to the comparison step. 

In a further aspect of the present invention, a navigation engine program product is 
provided, comprising: a confmter usable medium having conq>uter readable program code 
5 embodied therein conq)rising: first code for transforming data-centric hierarchical storage and 
retrieval mechanism data to presentation language; second code for receiving data in 
presentation language and converting the received data to the data-centric hierarchical storage 
and retrieval mechanism; third code for performing attribute based validation on the data; 
fourfli code for providing navigation among present pages; and fifth code for saving the data in 
10 response to a command. 

In yet a further aspect of the present invention, a method for processing forms on a 
user-interface program is provided, cominising the steps of: receiving an engme and a file 
with a form including a schema and a template in a data-centric hierarchical storage and 
retrieval mechanism; transforming with the engine the form from the data-centric hierarchical 
15 storage and retrieval mechanism into presentation language and presenting the form at the user- 
interface program; receiving user input data in the presentation language; converting the user 
input data to the data-centric hierarchical storage and retrieval mechanism; performing attribute 
based validation on the converted user input data; incorporating any error detected in the 
validation step in the data-centric hierarchical storage and retrieval mechanism into the form 
20 schema or separate form schema; converting the any error into presentation language and 
presenting an error message associated therewith to the user; allowing the user to correct the 
user mput data, if necessary; and saving the user mpxxi data. 

In a yet further aspect of the present invention, a runtime environment method for an 
electronic forms implications is provided, comprising the steps of: receiving a forms request 
25 from a use:i-mtei£^ prograim; deterraiinng \i the Tastr-toawface progim is t^onxpatibte or not 
compatible with a data-centric hierarchical storage and retrieval mechanism; sending from a 
computing resource to the user-inter&ce program, if the user-interface program is compatible 
with the language, a schema file containing form information to be inserted into a form 
template and a form navigation engine and a form input validation engine; if die user-inter&ce 
30 program is not compatible with the storage and retrieval mechanism, sending user input 
information to the computing resource for processing and sending a presentation language 
version of form pages resulting from the conq)utihg resource processing back to the user- 
interface program. 

-2- 
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In a yet further aspect of the present invention, a method for creating a fonn file is 
provided comprising the steps of: storing in a form file a path to a schema in a first file at a 
storage location; storing in the fonn file a path to a template in a second file different from the 
first file at a storage location; and storing the form file at a user location. 
5 In a yet further aspect of the present invention, a method for performing customized 

actions in a computing environment is provided, conpising the steps of: providing at least one 
selector file, each selector file containing at least one selector pattern and associated with an 
action set that contains at least one action, wherem the at least one action contains at least an 
eAgent ID and an associated action document ID; obtaining a document for processing from a 

10 queue; searching the document for a match to at least one of the selector patterns of the 
selector files; if a match is found for one of the selector pattems, executing the at least one 
action in the Actionset associated with the matched selector file, includu^ loading an eAgent 
specified by the eAgent ID; and the eAgent reading an action document specified by said 
associated action document ID and performing an action specified therein. 

15 In yet a further aspect of the present mvention, a system for generating forms in a 

computing environment is provided, conq}rising; a schema database; a template database 
sq)arate from the schema database; at least one Imkage file, each contaming code to link a 
selected sdbema with a selected template; a database of validation patterns separate from the 
schema database and the tenq)late database; and a database of query information separate from 

20 the schema database and the template database. 

In yet a further aspect of the present invention, a system for performing actions on 
documents in a computing environment is provided, conq)rismg: a selector file database 
containing a plurality of selector files; an Actionset database containing a plurality of 
Actionsets, wherein each selector file is associated with exactly one Actionset; an eAgent 

25 specific action document database contaming a plurality of action documents that are specific to 
eAgents; wherein each Actionset in the Actionset database is associated with at least one action 
document. 

In yet a further aspect of the present invention,^ a computer program product for an 
integrated development environment is provided, con]prising: a computer usable medium 
30 having a computer readable code embodied therein, including: presentation host code, the 
presentation host code includmg shared user interface and logic code components, code for 
reading a IDE configuration, and code for loading any IDE connponent code and business logic 
components code as defined in the IDE configuration; at least one IDE con^jonent code loaded 
by the presentation host on the user-interface program, the IDE component code mcluding a 
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user interface; at least one business logic conq)ODent code loaded by the presentation host on 
the user-interface program, the business logic conq)onent code defining the interrelationships 
between objects represented in the user interface. 

In a yet further aspect of the present invention, an integrated development environment 
5 method is provided, comprismg the stq>s of: loading onto a computer resource code in a 
tiered architecture conq)ri5ing: a presentation host tier that includes presentation host code» 
the presentation host code including shared user interface and logic code con^nents, code for 
reading an IDE configuration, and code for loading any IDE conq>onent code and business 
logic components code as defined in the IDE configuration; an IDE component tier, including 

10 at least one IDE component code loaded by the presentation host on the user-mterjfiace 
program, the IDE component code including a user interface; a business logic component tier, 
including at least one business logic conq)onent code loaded by the presentation host on the 
user-intorface program, the business logic ccmqponent code defining the interrelationships 
between objects rq>re5ented in the user interface; a data access abstraction layer tier, including 

15 a data access abstraction layer code that allows business conqx)nents code to read and write 
information to/from a computing resource; and communicating with a remote conq>uting 
resource through use of the data access abstraction layer code. 

In a yet further aspect of the present invention, a computer program product is provided 
comprising: a medium with machine-readable code stored thereon which gives the ability to its 

20 computer to perform form creation tasks, including: first code for facilitating a schema 
database; second code for facilitating a template database separate fi:om the schema database; 
third code for fecilitatiog at least one linkage file, eadx containing code to link a selected 
schema from the schema database with a selected template from the template database; fourth 
code for facilitating a database of validation patterns separate from the schema database and the 

25 texoplaie database; and fifth code fox facihtsting a database of queiy mf cmnaiion separate from 
the schema database and the tenq>late database. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a schematic block diagram showing the system architecture for the fonxis 
creation system and method of the present invention. 
30 Fig. 2 is a static block diagram of the overall invention architecture, including the 

forms creation system and method in combiaadon with the e-commerce system. 
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Fig. 3 is a process workflow block diagram for a client-side processing sofhvaxe 

design. 

Fig. 4 is a workflow block diagram for a server-side processing software design. 
Fig, 5 is a process workflow block diagram of a forms publishing software process. 
Fig. 6 is a static block diagram of an eAgent architecture. 
Fig. 7 is a process workflow block diagram for the eAgent architecture software. 
Fig. 8 is a static block diagram of an integrated development system for an e-commerce 
architecture. 

Fig. 9 is a schematic diagram of a forms schema. 

Fig. 10 is a schematic diagram of a regular expressions schema. 

Fig. 11 is a schematic diagram of a query schmia. 

Fig. 12 is a schematic diagram of a tenq>lates schema. 

Fig. 13 is a schematic diagram of a ten^Iate schema. 

Fig. 14 is a schematic diagram of a publishing folder schema. 

Fig. 15 is a schonatic diagram of an integrated development environment schema. 

Fig. 16 is a sch^natic diagram of an XML selector schema. 

Fig. 17 is a schematic diagram of an Actionset schema. 

Fig. 18 is a schematic diagram of an action query eAgent schema. 

Pig. 19 is a schematic diagram of a queue config schema. 

Fig. 20 is a sch^natic block diagram of a system for performing actions on documents. 
Fig. 21 is a sch^natic diagram illustrating tiiie publishing wizard-Publish. ASP 
interaction between the IDE and the server. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

The present invention, in a preferred embodiment, may incorporate technologies, 
including: 

• Extensible Markup Language (XML), both as an object store and as a data store 
for flexibility, extensibility and easy integration with other systems. 

• Extensible Stylesheet Language PCSL) and JavaScript, using the XML DOM as 
the transfonnation engine, for transforming the meta data of a form into an 
HTML form and for transforming one XML implememation into another. 

• Cascading Style Sheets (CSS), for manipulating the display of the XML Data. 
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• Dynamic HTML, for making use of client-side processing and updating page 
information without needing a roundtrip to the server. 

• Regular Ejqpr^ons, to enable validation and transformations of entered data. 

• Active Server Pages (ASP) for support of a multiple browser environment 

• COM components, for packaging complex segments of the process into more 
modular and scalable sections. 

• JavaScript, ifor validation and client-side navigation logic, as well as sever-side 
ASP code. 

• Microsoft Transaction Server (MTS), for supporting a large number of 
concurrent users. 

• A queue-based approach (usmg the file system or a message queue server), for 
maximum scalability, reliability, response time as well as integration with 
oflier systems. 

• A template-based ^qrproach, where template designers can design the teniplates 
that *'plug m" to the present invention, thus providing a highly customizable 
look and feel, as well as separation and specialization of tasks. 

• An ActiveX based integrated development environment (IDE) , for 
manipulation of XML files over the Internet using HTTP and the ability to 
associate the present invention with a template over the web - all usmg a 
gr^hical user inter&ce (GUI). This obviates the need for the forms designer 
to learn any of the above technologies to create and fnaintflin present 
invention. 

It should be noted that although the preferred embodiment is described in the context of 
current language types such as XML, HTML, CSS, and the other listed languages and 
conventions for ease of reader understanding, it is not intended to limit the invention to these 
languages and conventions. For example, the references to XML can be replaced by any data- 
centric hierarchical storage and retrieval mechanism; and HTML can be replaced by any 
apprc^riate presentation language. 

A number of terms that are used throughout the specification are defined below. 

Data-centric Hlerarcbical storage and retrieval mechanism 

A data-centric hierarchical storage and retrieval mechanism comprises the ability to 
store and retrieve hierarchically organized data. It mcludes both the format in which the data 
gets stored, as well as how to access the hierarchically organized data. 

Actiotv DcKument 
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A document that defines parameters for an action in the data-centric hierarchical storage 
and retrieval mechanism. 
Routing Document 

A routing document contains a document and tracks actions executed on the document 
by the eAgents. 
Action 

An action can contain one or more processes that may or may not be executed by an 
eAgent. 

eAgent 

An eAgent is a soilware component that performs the action on the routing document 
and on the associated action document. 
Queue 

A queue can be a folder, mailbox, queue server or any computing resource capable of 
queuing data. 

Code for facilitating a database 

Code for &cilitating a database enconq)asse$ the ability to set up, manq)ulate and/or 
maintain a database. 

Schema or Metadata 

Metadata or schonoa are data that describe the aspects of a form that change from form 
to form, excluding the exact (graphical) presentation. Examples will be provided below. The 
terms -schema" and "metadata'* are used interchangeably in this application. 

System Requiremeats 

The user of the present invention who wants to fill out a form only requires a browser 
capable of HTML 3,2 or other presentation language and basic CSS support, e.g. Internet 
Explorer 4.0 or above, Netscs^ Communicator 4.0 or above. 

The following table lists the requirements for the fonns designer and the server on 



which the present invention are used at tiie present time: 



Description 


Forms Designer 


Server 


Operating System 


Windows 95, Windows 98, 
Windows NT 4,0 
(workstation or server) or 
Windows 2000 (workstation 
or server) 


Windows NT 4.0 Server with 
service pack 4 (or above) and 
Option Pack (US 4 and MTS), 
or Windows 2000 Server 


Additional Software. 


Internet Explorer 5 


Internet Explorer 5 
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Minimum RAM 


32MB 


128MB 


Hard drive space 
available 


10 MB 


SMB 



Referring now to Hg. 1 there is shown a block diagram of the forms creation system of 
the present invention. The individual conq)onents shown in this figure will be described, 
followed by a description of how these components are controlled using flowcharts of the 
5 software of the present invention. The specific XML vocabularies used wUl be covered in a 
later section, that will include a tree diagram, explanation and samples. 

Schema Library 

An important aspect of the present invention is the use of Meta data or schema. 
As noted above, Metadata or schema are data that describe the aspects of a form that 
10 change from form to form, excluding the exact (graphical) presentation. Examples include but 
a^e not limited to 

> Name and caption of a field 

> Help text 

> What control type to use 

15 > Whether the field is required and any other validation rule 

> Whether to provide the user of the form with a lookup list, and the entries of the list. 

The following are exanq)les of what would not constitute Meta data or be part of the 
schema. 

> Color (background, font, etc.) 
20 > Fonts (type, size, bold, italic, 

> Positioning 

> Graphical elements, including lines, circles, logos, etc. . 

> HTML tags for display of input controls, e.g.. <INPUT> , etc. 

Using this approach allows the separation of content fi-om display, and the possibDity to 
25 change each one con5)letely independently of the other. 

The schema of a form is represented are typically represented in a specific XML or 
other data-centric hierarchical vocabulary, that includes diose elements and attributes needed to 
describe a form, but not its display inq)lementation. 
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An extremely sinoplified exanq)le would look like this: 

< form naine= "Registration" > 

< field name = "FirstName** required = **tnie"/ > 

<field name^^LastName" required=**true''/> 
5 < field name = "eMail** required= "true"/ > 

</form> 

The schema would be created by a forms designer and stored in a schema hT>rary 10. 
The schema library 10 provides the forms designer with the ability to reuse individual sections 
or fields or the entire schema in other forms. Any storage configuration may be utilized 
10 including remote and/or distributed storage accessible over a network, over the Internet, or in 
any other convenient fashion. 
Query Library 

In one aspect of the invention, in order to present the forms designer with a list of valid 
entries to populate form fields, fbc present invention provides the ability to gather the data for 
IS list/lookup from any ODBC/OLE DB con:q>liant database, including SQL Server, Access, 
Oracle, DB 2, DBase, Informix, Sybase, Microsoft Exchange and others. 

Instead of including the necessary information for executing a query directly into the 
native schema of a fonn, the present invention uses a query library 12 to store queries and only 
references than inside the native sdiema of the forms by the given name of the query. This 
20 results in the ability to have a central repository 12 of all database-related queries for ease in 
making changes and flexibility. Queries can be changed independently of the forms that are 
using them, and any saved changes take immediate effect. 

The queries themselves are defined using a specific XML vocabulary, and the 
connection information to the databases, in a preferred embodiment, is kept in Microsoft Data 
25 Lmk Files (udl files). 

Note that to j^cilitate the use of the query library to facilitate a central change to a 
query that is used in a plurality of different schema, the present invention, in a preferred 
embodimem, stores the schema in the schema library 10 in both a native schema format and a 
compiled format. In the native schema format, the schema includes one or more links to the 
30 query library at those sections of the fprm fields and sections that are to incorporate a 
particular query therein. The compiled schmia format is also stored and incorporates the 
query itself, rather than a link to the query. 

Updating a given schema with changes made to one or more queries would typically be 
accomplished simply by reconq)iling the schema. Alternatively, the updating can also be 
35 programmed to be accomplished at runtime. 
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Validatfon Library 

A validation library of regular expressions 14 is provided that contains a list of regular 
expressions. 'Regular expressions' is a pattern matching technology, that allows for the 
comparison of an input string against a pattern (regular expression), and that evaluates whether 
3 the pattern is foimd in the mput string. In this way, a variety of validations can be executed 
when a user ii5)uts data into an electronic form, including checking for valid email, zip, state, 
phone, SSN, etc. Each regular expression is given a user-friendly name and is called from the 
schema library 14 by the forms designer using that name. The regular expressions library 14 
may conveniently store the regular expressions in XML or other convenient data-centric 
10 hierarchical storage and retrieval mechanism. 

The same approach may be used as was used for the queiy library. The native schema 
stored at in the schema library 10 may include one or more links to regular expressions stored 
m the regular expressions library 14. The compiled schema stored in the schema library 10 
would include the particular regular e7q>res5ion wiAout the link to the regular expression 
15 library 14. Accordingly, regular expressions can be updated by one central change to the 
re^gular expression Jibrary 14, which change can be pxopatgated through all of the schema in the 
schema library 10 using that regular expression simply by recompilbg the particular schema. 
Twjdates 

A Template is a collection of files, that may include ASP, CSS, images and other 
20 convenient hems, which define the layout of the page in which the forms using that tenqplate 
are rendered. The layout typically mcludes the conq»any logo and a navigation bar to allow the 
user to navigate to other pages of the site, plus the look and feel of the page, includmg colors, 
fonts, positioning, and other aspects. 

The present invention enables leveraging the fiiU power of ASP/HTML/CSS to format 
2S the page most ways that the forms desiguec may wuh to display the form. The template files 
can be designed with any tool that can create ASP/HTML/CSS, including Front Page, Visual 
InterDev, Dream Weaver or even a simple text editor. The templates that are created are 
stored in a template library 16. 

To make an ASP page a template, a designer sunply needs to enter appropriate lines of 
30 code into his/her ASP page (done automatically when the form is published to the W^) and 
create additional descriptions in associated XML files. 

The present invention allows the forms designer to easily select a template from the 
teoGqplate database 16 with which to associate a schema. 

Disphy and Navigation Engine 
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Tasks 

Also included in the system is a display and navigation engine that performs the 
following tasks 

> Transforms the XML forms mto HTML forms. (r> Forms translator) 

5 > Takes the input into HTML forms and transfers the data back into XML for^ 

Forms extractor) 

> Performs validation logic that only allows submission of valid data and notifies 
users of errors and what needs to be corrected. 

> Displays a preview page for user verification of entries. 

10 > Page navigation to allow moving forward and backward, including ensuring that 

any entered data are saved (i.e., NEXT, PREVIOUS, SUBMIT). 

> Saves the submitted fDrm data and relevant schema into a queue (the prefened 
inq>Iementation uses file system as a queue). 

In order to accomplish the foregoing tasks several components are used. What they are 
15 and how they are used is described in the following sections. 
Climt-Side vs. Server-Side processing 

In a preferred embodiment, tbsxe are two versions of the display and navigation engine 
18. For clients that use Internet E7q;)lorer S (IE S) or other browsers that are conq)atible with a 
data*centric hierarchical storage and retrieval mechanism, a substantial portion of the 
20 processing may take place on the client-side (browser). For other clients that are not 
compatible with a data-centric hierarchical storage and retrieval mechanism, all the processing 
occurs on the server. Both versions share some components / component logic, while some 
parts are specific to each version. 

This preferred embodiment using two types of display and navigation engines is utilized 
25 m order to support a substantial number of browsers. Note that the display and navigation 
engine for DE 5 and other similar type browsers use the client-side functionality to offload 
processing to the client and thereby obtain unproved performance (no server round trips) and 
higher scalability Gess server processing needed). 

At the present time Internet Explorer 5 comes with sufficient support for the XML 
30 DOM (Data Object Model), XML data islands, XSL and DHTML (Dynamic HTML), which 
are used to iir5)lement a client-side version of the present invention. Future browsers that 
support these or conq^arable technologies will also su{^ort client-side processing. 
Forms Translator 
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Current browsers have no standard way of displaying any XML or other data-centric 
hierarchical elements in a meaningfol way* The present invention uses a forms translator in 
the display and navigation engine 18 to transform the XML forms into HTML forms. 

The forms translator, in the present design, is uq)lemented primarily as XSL style 
5 she^. The Extensible Stylesheet jLangoage (XSL) allows the transformation of XML into 
another form of XML, HTML or any other text based format. 

The forms translator maps m a standard ^ishion the relevant XML elements and 
attributes to HTML elements and attributes, and supports multiple controls, field level help, 
error messages. 
10 Forms Extractor 

Once the data has been entered into the HTML form by a user, the data must be 
extracted again into XML by the display and navigation engine 18. The mechanism used to 
accomplish this is a naming convention. The format for this convention is as follows: 
fld_ < controltype > _ < secdonname > _ < fieldname > 

15 where : 

"J* is the delimiter that separates the parts to be parsed 

"fld" is the prefix which indicates that a form variable is related to the XML DOM data 

<controltype> is a descriptive (not necessarily directly Usted in the XML DOM structure, 
example "selectmulti'* might require a match of controltype attribute- 'select* and multiplselect 
20 attribute^ yes) terna vised to uniquely identify a control type in the XM^ Acontroltype 
is a reference to the XML representation of an HTML display type, such as text box or select This 
approach allows the forms des^er to define custom controls, such as a date picker control, which 
constitutes a composition of several simple centred. 

<sectionnanie> and <fieldname> are the name identifiers of the section/field. 

25 The server-side version uses the ASP Request object to retrieve the information 

entered^ and using the naming convention above transfers the information into XML. The 
cli^t-side version uses DHTML, m the preferred embodunent. 

The conversion to the data-centric hierarchical storage and retrieval mechanism may 
occur ahnost simultaneously with the data entry, or may occur periodically, or may 
30 conveniently occur when the user clicks NEXT. 
Validation 

Most typical validation in the prior art acts directly on the user interface. This 
approach tightly couples the validation to the display mechanism and offers little flexibility. 
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The present inventive approach allows the validation to work no matter what user 
interface has been chosen. This is accomplished via the display and navigation engine 18 by 
first converting the infomnation from the display to the XML or other data-centric hierarchical 
storage and retrieval medianism, and only then performing the validation on the XML 
5 converted data. 

By using this approach, the same source code (or the same logic) can be used by both 
the client and the server-side version of the validation software, and the present invention is 
able to support changes in the user interface without having to change the validation logic. 

The validation logic in the display and navigation engine 18 itself also does not 
10 communicate directly with the user interface once errors have been found. Instead it flags the 
erroneous field/section by including an error message inside the XML-converted data. This 
offers the advantage of being able to customize how the error message is displayed to the end 
user. 

The validation component functions to check every field for all validation rules defined 
15 and stops processing tbsd field/section once/if the first error has been found. 

Another k^ part about the validation is the ability to use attribute-based validation. 
Exanq)les of attribute-based validation are "required," "maxlength,* "minlength," 
"minvalue," "maxvalue," and "pattern." Ail that the forms designer needs to do is specify a 
value for that attribute, and the validation component will ensure that the validation is 
20 performed accordingly, and the display engine will ensure the error is conornxmicated to the 
end user. 

By using this ^proach, non-programmer forms designers can perform 95% or more of 
the typical validation on most of the forms without having to do any programming. 
Preview Page 

25 the preview page for the display and navigation engine 18 is simply a read only view 

of the cq)tion and values of the fields entered by the end user. The current implementation of 
the innovation uses an XSL style sheet for the display. 
Page Navigation 

Page navigation on the client is handled by local Jscript in a preferred embodiment in 
30 order to in:q)lement the NEXT, PREVIOUS, AND SUBMIT commands. 

Note that the server-side version of the display and navigation engine 18 (for nonXML 
compatible browsers) needs to keep track of the current section being displayed to the user. 
This is accomplished by passing a section number as a hidden textbox for every display. 
Maintaining state 
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The data entered by the end user is transferred into the XML document tbat contains 
the schexna. For the client-side version of the present invention» there is no other problrai 
associated with maintaining state. 

For the server-side version of the invention, additional code has to be added, because 
HTTP is a connection-less protocol. The solution used by the present invention is to store the 
XML converted data as a file with a unique identifier on the server, and to pass this unique 
identifier in a hidden textbox from page to page. In this way any previously entered data is 
available when navigating among pages. 

Submission 

The typical action in prior art designs when an end user is submitting form data (which 
generally will occur when the end user clicks SUBMIT) is to directly and synchronously act on 
the data, e.g., write to the database, send emails, etc. This approach results in the end user 
being required to wait until all these actions are completed, and in case of the database being 
offline, the user losing all of his/her data. 

The present invention instead uses a queue-based ^proach, where all data entered and 
relevant schema are simply written to a queue, and an acknowledgement is sent to the user for 
his/her submission. 

The queue mechanism has several advantages: 

• Quicker site response time. The user does not need to wait until the actions 
based on his iiq)ut are performed. 

• Queues don't lose data even if the connection between the Business Her 
Server and the Database Server is down. Messages will continue to be 
queued in the queue, and processing will continue as soon as the connection is 
restored, 

• Forms a log file of transactions. Allows for every insert request to be logged. 

• Independent changes— the processing performed on the submitted data can be 
changed con^letely independently from the forms themselves, as long as the 
structure of the form message remains the same. 

It should be noted that in the preferred embodiment, the client-side version (i.e., 
compatible with XML or other data-centric hierarchical storage and retrieval mechanism) 
submits its data usmg the XMLHTTPRequest class from Microsoft's XML parser to send the 
XML to the web server. This again reduces the processing the server needs to perform, 
because the transferring of flie end user-entered data in the HTML form to XML has already 
been performed by the client browser. 
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Use Of XML in The present invention vl.O Programmatic Creation / Reading of 
XML files 

The present invention provides GUI tools to edit XML files. The XML ffles 
themselves are never direcfly exposed to the forms designer* Using fliis approach ensures the 
5 consistent, OTor-free creation of the relevant XML files and facilitates use by the forms 
designer. 

All of the tools that are needed to create the XML files arc embedded into an IDE for 
easy access and consistent use. 

Server- and Client- side Flowdiarts 
10 The followmg figures are intended to clarify the processes that are occurring within the 

server-side and client-side nnplementations of the present mvention, while highlighting the 
differences. The differences are primarily due to how the memory and instruction control and 
execution is partitioned differentiy between the different inq>lementation$. Both have 
ftmctionality reqmred of the server and client but differ m where the prin^ry processmg 
15 occurs. 

Clow Descriptions - Process Workflow of client-side processing 

Referring now to Fig. 3, there is shown a schematic flow diagram of the present 

invention for the client-side implementation (XML or data-centric hierarchical storage and 

retrieval mechanism compatible browsers). 

20 > Server receives ASP or other standard page request. 

It should be noted that instead of ASP, which is the prefened embodiment, any server-side 
scripting/programming solution, such as JSP, could be used. 
> Step A: 

The server-side software processes the request at runtime. This encompasses: 
25 > Loading the sdiema. 

> Optional mitializing the schema (on the fly modification) by a custom ASP sctipU 
i.e. adding a field at runtime. 

> Preprocessing the schema for any database lookups. 

> Optional initializing values by a custom ASP script, i.e. populating a form with 
30 values at runtime. 

> Putting out the resulting schema as an XML island as part of the HTML page that is 
sent to the client 

> Sending the foU HTML page with the XML island down to the browser. 
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> StepB: 

After the HTML page and all associated files (XML, XSL, CSS. JavaScript, images) have 
been loaded, set the first page to be the active page and call step C p display it. 

> StepC: 

5 The client-side runtime software calls XSL style sheets to the sdiema file to display the 
active page of the form. It is here where the schema of die form is converted to HTML. 
The conversion inchides fbrm/page/section headers and help text, as well as information 
regarding input fields. This includes captions, different HTML controls to c^ture input 
for them, required icons, error messages in case there have been any errors, etc. 
10 The transformation/conversion uses dynamic HTML to change the content of the page after 
it has been loaded or afla: an end usct has navigated to a new page by clicking NEXT or 
preview. There is no need to roundtrip to the server. 

> Stq>D: 

Here the user enters his/her data and clicks on navigation controls to move 
15 forward/backward. The client-side display and navigation software awaits the activation of 
a navigation control. 

> StepE: 

Having activated a navigation control, the client-side runtime software transfers the entered 
data of the page into the schema, which resides as an XML island inside of the HTML 
20 page. 

> Stq)F: 

In this step, validation is executed for all sections/fields of this transferred page. The 
outcome of the validation is documented inside the schema. 

> Steps Fl and F2"Page calculation: {Errors?/Last Page?) 

25 > If an error has been found, then step Fl causes the same page to be displayed again 
(stqjC). 

> Otherwise in step F2 it is checked whedier it is the last page. If At is the last page, then 
a preview page is shown. (stepG) 

Note that the preview is optional. If the preview is disabled for this form instance then the 
30 data gets submitted after the last page has been filled and the submit button activated. 

> If there is neither an error nor the last page, the active page is being set as requested, i.e. 
the next or previous one and then displayed (step O 
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> Step G: 

Using a style sheet for preview, the information entered in the schema is transformed to an 
HTML preview page and displayed. 

> StepH: 

5 After having qlicked NEXT/SUBMIT on the preview page, the XML schema is 

transformed into another XML document using an XSL style sheet for this purpose. This 
allows, for example, reducing the size by only includmg needed mformation, digitally 
signing the document or transforming into any other desired format. The transformed 
XML is sent to the server. This procedure of scaling down the size of the document 
10 (deleting items such as display-related attributes, such as the control type to use, the width 
of the control, and validation-related attributes, sudi as the isvalid flag and the 
errormessage attribute) is used to conserve bandwidth. 

> Step I: 

The XML is received on the server and submitted to a message queue (e.g. , the file system 
15 or MSMQ). Optional post'^)rocessing is executed. Then, an acknowledgement is sent back 
to the browser* Optionally, a redhrection to the next form, home page or other page is 
done. 

Flow Descriptions - Process Workflow of servernside processing 
Referring now to Fig. 4, there is shown a schematic diagram of the execution flow for 
20 server-side processing that will be implemented if the browser is not compatible with a data- 
centric hierarchical storage and retrieval mechanism such as XML. 

> In the initial step the server receives a request from an end user browser. 

> Step A: 

The runtime software loads and preprocesses the schema designated in the end user request 
25 ffle. 

The loading and preprocessing wzy be in a preferred embodiment, identical to the client- . 
side version, including the optional initialization of the schema or initialization of the 
values by a custom ASP scrq)t, with the following exception: 
The schema gets saved to a tanporary folder on the server. 
30 The active page is set to be the first page. 

> StepB; 

The runtime software applies multiple XSL style sheets in the well-known mamier to 
convert/transform the first page of the schema fi-om XML to HTML. The transfonnation 
includes form/page/section headers and help text, as well as information regarding input 
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jfields. This includes captions, different HTML controls to capture inputs required icons, 
error messages in case there have been any errors, etc. Also included are two hidden 
textboxes that contain the globally unique ID assigned to this form instance and the active 
page number. As noted earlier, this unique ID allows the server to keep track of which 
cli^t called. 

> StepC: 

The server sends the resulting HTML to the browser. 

> StepD: 

The browser displays the page. Note: there is mmimal or no runtime software on the 
client* i.e. no JavaScript, no XML nor XSL. 

> StepE: X 

The user may now fill in the values for the fields and use the navigation buttons. 

> Step P: 

Upon activating a navigation button, all of the field values ii^tted by the end user plus the 
values irom the bidden textbox (globally unique ID and active page number) are sent to the 
server, as well as which navigation control was chosen by the user. 

> StepG: 

The runtime software on the server extracts the unique ID from the received data and loads, 
the saved schema. 

> StcpH: 

The server runtime software then transfers page values to the designated schema using the 
ASP Request object to read the incoming data and the XML DOM to write to the schema. 

> Step I: 

The server runtime software then validates the received page values against all validation 
rules and updates the schema with any error infonnation. The schema is then saved again 
on the server using a unique ID. 
Steps II and 12-Page calculation: (Errors? / Last Page?) 

If errors occurred, then step U causes the same page to be displayed again (with the error 
messages). 

Otherwise, if it is the last page, tiien step 12 causes the preview to be shown (Step J). If it 
is not the last page, then step H causes the execution to update the active page number and 
displays that page (Step B). 
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Note that the preview is optional. If the preview is disabled for this form mstance then the 
data gets submitted after the last page has been filled and the submit button activated. 

> Step J: 

The server runtime software then uses XSL style sheet to transform schema (with data) into 
HTML for the preview page, as well as adding hidden tcxtboxes for globally unique ID and 
acdve page number. 

> StepK: 

The server then sends the transformed HTML to the browser. 

> StepL; 

Browser displays preview page. 

> StepM: 

The user then clicks PREVIOUS or NEXT/SUBMIT. If the user clicked NEXT/SUBMIT, 
then the browser seeds to the server the globally unique ID and active page number m step 
M. 

> If the user did not click NEXT/SUBMIT, then the last data entry page is shown again (step 
B). Otherwise it goes to final processing (step N). 

> Stq)N: 

The runtime software at tibe server then loads the saved schema using the globally unique 
ID. The XML schema is transformed into another (typically) reduced-size XML document 
using an XSL style sheet for this purpose. As noted previously, this conversion reduces 
the size of the document by only including needed information, digitally signing the 
document or transforming into any other desured format. The resulting schema is saved to 
the message queue. Optionally a post-processing script is executed. The runtime software 
then sends an acknowledgement and/or next form/page to the browser. 
Process Workflow of eAgent Architecture 

Referring to Fig. 6, there is shown the basic system configuration for the eAgent tiered 
processing architecture of the present invention. It should be noted that this system 
architecture may be used independenfly of the forms creation and completion processing 
discussed earlier. Referring to the figure, one or more message queues 26 communicates with 
a queue abstraction layer 40. The queue abstraction layer 40 communicates with a queue 
manager 42, which, in turn, communicates with an eAgent manager 44. The eAgent manager 
44 then communicates with an eAgent action coordinator 46. The eAgent action coordinator 
46 provides communication among a plurality of eAgents 48-60. Each of these elements 40-46 
is a configurable XML COM component. The fimctions performed by these conqwnents will 
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be discussed below. The configuration provides a decoupled eAgent architecture in which 
action conqx)nents can be added without having to recompile any code, stop and restart any 
services, or internet functionality in any way. 

Fig. 7 provides an execution flowchart for die architecture disclosed in Fig. 6, 
5 > Step A: 

The eAgent manager 44 loads and reads its configuration settings documents 45. The 
configuration settings on the documents 45 include which queues 26 it should communicate 
with, where selector files (to be discussed below) are located, how nmy r^ies to perform 
for each XML document, and other initialization information. 
10 > StepB: 

The eAgent manager loads and caches selector XML documents 47 for later use. XML 
selector documents inform the eAgent Manager which action sets to perform for each XML 
document that it receives from the Inbox. The selectors use a content based selection using 
XSL patterns. 
15 > StepC: 

The eAgent manager 44 instructs the Queue Manager 42 to poll an Ixibox Queue 35 in the 
message queues 26 for XML documents. The Queue Manager 42 destructively reads the 
XML document, and copies the document from the queue to an In-Process Qu^e 34 and to 
a log queije 37. It then sends the XML document to the eAgent Manager 44. 
20 > Note that step B and C occur periodically. 

> StepD: 

The eAgent manager 44 now tests the incoming XML document against each selector 
document 47 that has been loaded mto the eAgent manager 44. A selector document 47 
contains one or more XSL selector patterns that are associated with an Actionset ID. The 

25 test involves applying the XSL selector pattem(s) to the XML document and determining if 
any matches were found. If matches for one or more (as configured) XSL selector pattern 
were found, then an Actionset designated by an Actionset ID associated with the particular 
selector pattern will be executed (not in this step). . If no selector pattern matches are 
found, then it continues to step EZ. If the eAgent Manager 44 finds one or more 

30 Actipn5et(s) ID's for Acdonset(s) to execute, it continues to Step E. In addition, the 
eAgent Manager 44 creates a routing document, to which it attaches the incoming 
document. The purpose of the routing document is to provide tracking functionality of 
actions performed on the XML document, m addition to routing the document itself. 

> StepE: 
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If an Acdonset ID is found (i.e., a matdb to a selector pattern has been detennined), then 
the eAgent Manager 44 instructs the eAgent Action Coordinator 46 to load an Actionset 
document 49 associated with the Actionset ID associated with the matched selector pattern 
in step D, and execute the actions specified in this Actionset document 49. 
5 > StepE2: 

If the eAgent Manager found no matching selector file for the current XML document, it 
instructs the Queue Manager 42 to remove the XML document from the In-Process Queue 
34, and add it to the Dead-Letter Queue 33. 
> StepF: 

10 The Actionset file 49 includes at least one action, with that action containing a ProgID or 
GUID for a relevant eAgent, plus an action document ID. Based on the Actionset file 49 
specified in steps D and E, the eAgem Action Coordinator 46 loads an eAgent (48-60) 
specified by a ProgID for the Actionset file 49 and mstructs the eAgent to perform the 
relevant task by passmg it to the associated document ID. 

15 > Step G: 

The loaded eAgent reads the action docunoient associated with the specified action document 
ID (fix>m the Actionset file 49) (each eAgent has its own type of associated Action 
document whidi tells it which internal mediods to call for each action specified by the 
eAgent Action Coordinator 46), and performs the requested tasks. 
20 > StepH: 

Once the tasks are completed, the eAg^ returns any resulting data from its actions to the 
eAgent Action Coordinator 46. The eAgent coordinator 46 adds information to the 
routing document. Typically, this information will relate to the eAgent action, and may 
provide mfonnation on the completion or non-completion of the action by the eAgent. The 
25 information may also include a time-stanq> for the time when the eAgent commenced its 
action, and a time-stamp for when the eAgent completed its action. This information may 
include results firom the action performed by the eAgent. This information may be 
readable from the routing document by other eAgents. Note that the time-stamp 
information provides a time history of activity for tracking purposes. 
30 • If the action was not successful, the eAgent Action Coordinator 46 informs the 

eAgent Manager 44 that the action was not successful and passes the routing 
document and the attached XML document to the eAgent Manager. It will also 
add information relating to this non-conopletion to the routing document noted 
above. 
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• If tbe action was successful, the eAgent Action Coordinator adds this 
information to the routing document* and checks if this was the last action 
specified in the Actiooset. 

• If it was not the last action^ step F is performed again for the next action in the 
5 Actionset. 

• If it was the last action^ fiicn the eAgent Action Coordinator 46 checks if the 
current Actionset is the last Actionset specified in the original selector jSIe for 
this XML document. 

• If it was not the last Actionset, the eAgent Action Coordinator 46 moves to step 
10 E for the next Actionset. 

• If this was the last Actionset, it passes the routing document with the included 
original XML Document back to the eAgent Manager 44. As noted above, the 
routing document will inchxde information on whether ail the Actionsets for this 
XML document were successful or not. 

15 • If the Actionsets were not successful, the eAgent Manager performs step II and 

either writes to the error queue 30 or the retry queue 31, depending on the 
eAgent manager configuration settings, and removes the document irom tbe in^ 
process queue 34. 

• If the Actionset(s) were successful, the eAgent Manager 44 performs step 12, 
20 i.e., it sends the routing document with the original document and pertment 

information attached to a journal queue 32, and deletes the document from the 
m-process queue 34. 

• In addition, as noted above, timestanq)S are added to the routing document 
detailing when the action was initiated and when complete. 

25 > Stg>Il: 

If the Actionsets were not successful, the eAgent Manager sends the routing document to 
the Error Queue 30, or to the Retry Queue 31. The configuration settings read in step A 
specify how many times an action should be retried and how long to wait between each 
retry. This determines whether the eAgent Manager 44 sends the XML document to the 
30 Retry Queue 3 1 or the Eriror Queue 30. The eAgent Manager 44 also deletes the routing 
document from the In-Process Queue 34 since it is no longer in process. 
> Step 12: 
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If tbe Actionsets were successful, the eAgent deletes the XML document form the In- 
Process Queue, and places it in tbe Journal Queue, mdicating success (and logging tbe 
document for auditing purposes) . 

To summarize the organization^ each selector file includes one or more patterns, and 
will be triggared when one or more of tbese patterns are matdied in the incoming 
document. The selection of which and how many patterns must be matched is determined 
by the processing designer. Each selector file includes only one Actionset (although 
Actionsets can be nested). Each Actionset includes one or more actions. Each action 
includes the designation of one eAgent ID and an action document ID. 

It should be noted that Actionsets may include branching commands, repetition 
commands, parallel execution commands, and tune controlled execution commands. 

The present invention also encompasses a system shown in Fig. 20 for performing 
actions on documents in a conq)uting envkonment. The system comprises a selector file 
database 300 containing a plurality of selector files, with each selector file including one or 
more patterns. The system further comprises an Actionset database 302 including a 
plurality of Actionsets, with each Actionset including one or more actions that reference an 
eAgent ID and an action document ID. Each selector file is associated with exactly one 
Actionset (but there may be nesting of Actionsets). The system further includes an eAgent 
specific action document database 304 containing a plurality of action documents that are 
specific to eAgents. Note that each Actionset is associated with at least one action 
document. 

The system may further include at least one creation module for creating and/or 
manipulating entries in one or more of the databases 300-304. 

The system may further comprise a processing co^:^)onent 306 programmed with code 
for allowing a designer to select at least one of the selector files from tbe selector file 
database 300, code for allowing the designer to select at least one of the Actionsets from 
the Actionset database 302, code for specifying at least one eAgent specific action 
document from tbe eAgent specific action document database 304, code for linking tbe 
specified selector file from the database 300 with the specified Actionset from the database 
302, and code for linking the specified Actionset with the specified action document. 
Referring now to Fig, 8, there is shown a system block diagram of an integrated 
development environment (IDE) architecture in accordance with the present mvention. The 
IDE architecture of Fig. 8 is based on a distributed, n-tier architecture, that allows sharing of 
both user interface and business components with centralized, dynamic configuration and 
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automatic distribution. This is described in detail in the following sections. Note that the term 
'^tiered architecture" means that a conq)onent in a given tier can communicate with other 
conxponents in the same tier or with components in immediately adjacent tiers only. 
Distributed " Accessing nies/XML documents over the Internet 
5 Accessing files/XML documents is performed using a file system abstraction layer 100, 

an ASP File System client implementation 102 and an ASP File System server inQ)lementation 
104. 

The file system abstraction layer 100 is an interface that defines and contains common 
file manipulation functions, such as readmg, writing and deleting files/documents. 
10 The ASP File System client implementation 102 inq>Iements an interface and 

communication between the file system abstraction layer 100 and the server implementation 
104 using its own XML-based simplQ file access protocol (SFAP). SFAP includes the 
commands as defined in the file system abstraction layer in an XML format. 

The server inq>lementation 104 performs actual file manipulation, e.g. reading a file 
15 and comnnmicates with the client-side ixnplementation 102 using the SFAP. 

ThCTefore, the user (i.e., the business con5)onents) of the file system abstraction layer 
100 can manipulate files/XML documents over the Internet simply by using the functions of 
the file system abstraction layer. 

N-ticrs 

20 Presentation Host Tier - IDE host. 

An IDE host tier 110 is shown in the figure defines an environment into ^^ch different 

user interface components (IDE components) can be plugged in. The host does not provide 

any end user functionality itself, but defines a standard set of interfaces for IDE conq>onents to 

implement, including i 
25 a) A shared library of user mterfece and logic elements, inchxding treeview, 

listview, toolbar controls. 

b) A consistent navigation system, regardless of the IDE component. 

c) A set of "standard actions, " such as new/edit/delete 

d) Provision to supply custom controls. 

30 e) Ability to have varying number of IDE components hosted. 

Inq)ortant additional aspects of this configuration include: 

> Implemented both standalone and inside a browser. 

> Support for standard actions 

> Support for sharing business components 
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Note from the above, that along with the shared user mterface and logic code 
components, the presentation host 1 10 includes code for reading any IDE component code and 
business logic component code that may be defined by an DDE configuration 107. The IDE 
configuration block 107 stores a file for each of a plurality of different roles, with the file for 
5 each different role including the ID's and other appropriate information for the coniponents 
that are to be loaded into the computing resource or browser that is to perform that given role. 
Pres^tation Controller Tier - IDE components 

The IDE conq>onents 108 im{>lement the interfaces defined in the IDE host 110 and are 
the components that actually define the interactions with the end user, and include such IDE 
10 Components as eAgent Actions code, Foim Schema code, Queries code, and Regular 
Expressions code. They do not include die business or application logic. The IDE 
conqx>nents code is typically loaded to the browser or other computing resource by the 
presentation host 110. The IDE components 108 also typically have associated custom 
controls. Custom controls are requured for the result pane of the window (right hand side of the 
15 IDE) if some other view than die listview is to be shown. 
Business Logic Her ^ Business Componrats 

The business components 106 implement the business rules/application logic for that 
component for its associated component 108 in the presentation controller tier. By way of 
exanq)le, the logic for the select query component m the business logic tier might include a 

20 selectquery class with a method "checkifvalid'' that checks if all necessary information has 
been provided and all data entered is valid. Likewise, the logic for the form schema con^nent 
in the business logic tier might include classes for the relationships between forms, pages, 
sections and fields, where these classes have attributes that describe the objects, such as a 
caption attribute of the field class. 

25 Data Access Tier 

This tier includes code to allow the business component code to read and write 
information to/firom a conq)uting resource. In a preferred embodim^t, the tier includes the 
file system abstraction layer 100» the file system client implementation 1Q2» and the file system 
server implem^tation 104 described above. 

30 Data Tier 

This der includes an eAgent repository 105 which includes selector files/ Actionset and 
eAgent specific action document databases, the schema Ubrary 10, the query library 12, the 
validation library (regular expressions) 14, and the IDE configuration 107. These 
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rqiDsitories/libraries are where the actual XML documents reside. This could be in the file 
systena or in an XML database. 

Sharing of User Interface Components 

The IDE host 110 allows the sharing among components 108 of common interface 
5 elements, such as toolbar, treeview and listview. In regards to the treeview, the IDE host 110 
also creates a "virtual root" for each IDE component, so that each IDE component may only 
see and manipulate its part of the tree. 

Sharing of IDE coii:5)onents allows for a lower footprint, e.g., instead of five treeview 
controls, only one is used. 
10 Sharing of Business Components 

Unlike any other system, the IDE host 110 has the e^licit fecility of using business 
components 106 to implement the business logic of the IDE components and the ability to 
share them between different IDE conq>onaits. As the exact same objects/instances are shared 
among different IDE components there are no synchronization delays. 
15 The instancing of business conq)onents is therefore not done inside the IDE components 

but instead from the IDE host. 

A configuration XML document that is located in the IDE configuration component 107 
defines: 

> which IDE and business components are to be loaded by the presentation host 1 10 loading 
20 code; 

> which IDE components 108 are associated with which business components 106 

> any dependencies between business components; 

>' other configuration settings for each business component. 

Using this information the IDE host 110 creates instances of the business components in 
25 the proper order and passes thrai and &e relevant configuration inforcMition to the IDE 
components 108, which in turn pass the relevant information to then: business CQnqponent(s) 
106. 

Note: the IDE host may be conf)onentized. By way of example, in the preferred 
embodiment the IDE host is actually made up itself of at least 3 different components; a control 
30 con:q)onent, a communications and a configuration component. 
Centralized, dynamic configw^tion 

The configuration is centralized, i.e. it is set by the Web Server or other appropriate 
computing resource via the IDE configuration block 107 which lists the components that are to 
be loaded to a given browser or other imputing resource to carry oat a role. Thus, there is 
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IK) need to do the configaration on each client nsichine. This is because the configuration 
XML document resides on the Web Server in the IDE configuration block 107. 

Note that because of this architecture, the configuration of any given browser or other 
computing resource is dynamic* i.e., the IDE host 110 does not need to be recompiled if more 
5 or less IDE conqx>nents are to be loaded. The number of IDE (and business) conq)onents to 
load is determmed at runtime/startup. 
Automatic Distribution 

By usmg an ActiveX based solution running in Internet Explorer 5 or another browser 
software compatible with a data-centric hierarchical storage and retrieval mechanism, both 

10 installing and upgrading is handled automatically. This is hatidled by Internet Explorer, i.e., 
IE 5 checks at the beginning whether the components are regist^^ on the madiine or if the 
newest version is on the machine aiKi if not it automatically installs or upgrades the individual 
components onto tbe client madiine. 

To summarize one aspect of the present invention, there is provided an integrated 

15 development environment method, comprising the steps of: loading onto a computer resowce 
code in a tiered architecture comprismg: a presentation host tier that includes presentation host 
code, Hxe presentation host code including shared user interface and logic code components, 
code for reading a IDE configuration, and code for loading any IDE component code and 
business logic components code as defined in the IDE configuration; an IDE component tier, 

20 including at least one IDE component code loaded by the presentation host on the user- 
interface program, the IDE component code including a user interfiice; a business logic 
conqwnent ti^, including at least one business logic component code loaded by the 
presentation host on the user-interface program, the business logic component code defining 
the interrelationships b^een objects represented in the user interface; a data access 

25 abstraction lay^ tier, including a data access abstraction layer code that allows business 
components code to read and write information to/from a computing resource; and 
communicatmg with a remote computing resource through use of the data access abstraction 
layer. 

Process Workflow Diagnun of Form Publishing Process. 
30 Referring now to Fig. 5 and Fig. 21, there is shown a workflow diagram for a forms 

publishing process and a schematic diagram of the IDE - server operation, respectively. With 
reference to Fig. 5, the process is as follows: 

> After saving a new form in execution block 200, the user is prompted in execution block 
202 to publish to the web or other location. 
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> If he chooses yes, then the publishmg process is imtiated 

> Step A: 

The publishmg wizard starts up and requests a list of templates fiom the "publish.asp" 
page. Note: this file can be named differently. 
5 > StepB: 

The "publish.asp" page reads the content from templates.xml and sends the list of available 
templates via the publishing wizard. 

> StepC: 

The publishing wizard presents the temphxts and after the user has chosen one, requests 
10 tenq)late specific questions and a list of available publishing folders from "publish.asp" 

> StepD: 

The "publish. asp" page opens the specific "tenq)late.xml** file designated by the responses 
to the template specific questions, plus opening the ''fblders.xml" for the available 
publishing folders. It then sends this information to the publishing wizard. 
15 > StepE: 

ITie publishing wizard presents the tenqjlate specific questions, collects the answers, 
presents the available publishing folders and lets the user select one. As the last step the 
user may give the published form a name and caption; the defauh is the name and caption 
of the schema. 
20 > StcpF: 

The "publish.asp" page packages all of the needed information into one XML document 
and sends it for processing. This may be synchronous as shown in the diagram, or 
asynchronous via a queue. 

> StepG: 

25 The publishing component copies processed) template items in selected publishing folder 
for later display. 

Referring now to Figs. 9-19, schematic diagrams of various schema are illustrated. 
Fig. 9 shows a fonns schema. Fig. 10 shows a regular expressions schema. Fig. 11 Shows a 
select query schema. Figs. 12 and 13 show template schema. Fig. 14 shows a publishfolders 
30 schema. Fig. 15 shows an IDE configuration schema. Rg. 16 shows an XML selector 
schema. Fig. 17 shows an Actionset schema. Fig. 18 shows an action Query eAgent schema. 
Fig. 19 shows a Queue Config schema. The various element/attribute descr5)tions are listed 
below. 
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Note: bold-faced items denote XML elements, non-bold-feced items denote XML 



attributes. 



Element/Attribute 


Description 


form 


The highest level element acting as a container for 
all of the data items that make np the intended form. 


name ' 


Unique identifier for the form. May only contain 
diaracters, no spaces or special characters allowed. 


caption 


Title of the form, may contain spaces and special 
characters. 


helptext 


Informative text such as instructions on what this 
form is about. 


page 


A subdivision of a form that typically is displayed as 
a separate page in the browser. 


name 


Unique identifier for the page. May only contain 
characters, no spaces or special characters allowed. 


caption 


Tide of the page, may contain spaces and special 
characters. 


helptext 


Informative text such as instructions on what this 
page is about. 


section 


A subdivision of a page that contains a number of 
fields for the user to enter. 


name 


Unioue identifier for the section Mav onlv contaf n 
characters, no spaces or special characters allowed. 


caption 


Title of the section, may contain spaces and special 
characters. If there is more than one section per 
page, the sections must contain a caption attribute, 
otherwise it is ignored. 


helptext 


Informative text such as instructions on what this 
section is about. 


isvalid 


true/£alse - flag reflecting the status of the section: 
true if the items within the group have no validation 
errors associated with the item, &lse otherwise 


errormessage 


Hie text that will be displayed if a validation rule 
has been broken 


jscriptvalidation 


A validation rule written in JavaScript that is to be 
evaluated for this section. No direct access to 
outside resources such as databases, etc. is needed. 


jscriptexternalvalidation 


A validation rule written in JavaScript that is to be 
evaluated for this section. Direct access to outside 
resources such as databases, etc. is needed. 


captionrow 


true if the section is to be displayed with the 
captions of all of the first element in each row of 
items on a separate row above the rest of the items 


field 


A data entry unit, which may be displayed in 
different fashions. A field is an entity that accepts 
user mput. 


name 


Unique identifier for the field. May only contain 
characters and digits (not as first letter), no spaces 
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or special characters allowed. 


cq)tioii 


Caption of this fields may contain spaces and special 
characters. 


helptext 


Informative text sach as instructions on what to 
enter in this field. 


isvalid 


true/false - flag reflecting the status of the item: 
true if no validation rules f3r this field have been 
violated, false otherwise. 


enormessage 


Error message being displayed to the user if a 
validation rule for this field has been violated. 


validexample 


A valid example for this field. 


jscriptvalidation 


A validation rule written in JavaScript that is to be 
evaluated for this field. No direct access to outside 
resources such as databases, etc., is needed. 


jscriptextmialvalidation 


A validation rule written in JavaScript fliat is to be 
evaluated for this field. Direct access to outside 
resources such as databases, etc. is needed. 


minlength 


The mininram number of characters required for a 
field. 


maxlength 


The maximum number of characters allowed for the 
field. 


required 


False if en:q>ty entries into this field are allowed, 
true otherwise. 


minvalue 


Minimum value allowed for this field. 


maxvalue 


Maximum value allowed for this field. 


capitalization 


Provide for automatic formatting of input, e.g. 
capitalize all, make all lowercase or put into proper 
case 


datatype 


AUowed mput fonnat. 


regexvalidatioo 


A regular expression pattern that is to be applied to 
the field value input. 


regexmcxiifier 


A modifying value that changes how the regular 
expression is applied to the field value: *i* 
(incasesensitive) will check the input value without 
regard to case and 'g* (global) will check for aU 
instances of the pattern (as opposed to stopping at 
the fust match). 


text 


The text node for the field. It contains the default 
value in the beginning and will contain the entered 
data from the end user as soon as the user enters 
data. 


display 


The display element provides basic information on 
how to display the field. 


samerow 


true if the item is to be displayed on the same row 
with the previous field. Not included if the field is 
the first field of a row. 


nowrap 


true if the values associated with the display of the 
field are allowed to wrap to the next line, false 
otherwise 



-30- 



SUBSTITUTE SHEET (RULE 26) 



wo 01/37170 



PCT/USOO/31221 



width 


width of the input control in diaracters. 


controltype 


Name used to determine how to display the field 
element that will be used to acc^t user input. 


cols 


Number of characters across to be displayed for a 
textarea display* 


rows 


Number of characters down to be displayed for a 
teTCtaiea display. 


multipleselect 


true if multiple checkboxes in a group of checkboxes 
or selections in a pull-down list may be selected. 
Not included if only a single value may be diosen. 


selectpronq)t 


Text to be shown as the first field in a pull-down list 
to prompt the user to select an entry. 


minyear 


Minimum year displayed in datepicker year select 


maxyear 


Maximum year displayed in datepicker year select 


multitextfonnat 


Format specifying how many textboxes to show and 
relevant properties, such as maxlength. 


multi 


true if more than one field are to be shown in a row. 


rownuinber 


A number identifying the sequence in which the 
fields will be displayed down the section. 


rowindex 


A number identifying the sequence in which the 
fields will be displayed across the page. 


entries 


Provides a list of possible values for this field, 
which may be used for display and validation 
purposes. 


isfroindb 


true if a query to a database is required 


qdef 


ID/Name of the query definition containing the 
query to return the list of entries 


entry 


A single entry. 


show 


The text to be displayed to the end user which may 
be different from the internal value stored 


value 


The value of that entry. 


parameter 


A parameter for use with queries that further 
specifies it. 


name 


Name of the parameter. Must correspond to the 
name of the parameter for the select query 


value 


The value for this parameter. 


custom 


An element that allows addition of custom data to 
any field or section as a name-value pair. 


name 


The name of the custom entry 


value 


The value of the custom entry 


data 


This element is a container for system, temp and 
user data that are filled at runtime. 


system 


Data needed by the system, such as path settings 


guid 


A globally unique identifier that is used to identify a 
specific mstance of a form. 


temp 


Temporary data needed by the system or the user 


pagenumber 


Number of the current page being displayed 


servcrpath 


URL of the web server containing the application 


■schemapath 


Location of the directory that contains the schema. 
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xslimagepath 


Location of the directory containing the images used 
bytheXSLfiaes 


user 


Element to place custom data regardin;; sections. 


7. Regular Expression 


Element/ Attribute 


Description 


regexdb 


Root elment, just a container of regex elements 


regex 


Contains a regular expression 


name 


The name of the regular expression. May only 
contain characters* no spaces or special characters 
allowed. Must be unique. 


pattern 


The pattern that describes what is looked for. 


glol>alsearch 


A rCEular cxoression modifier that defines whether 
the pattern shall apply to all of the string or only 
part of it 


casesensitive 


A regular exoression modifier that snecifies wheflier 
to take case sensitivity into account or not. 


description 


A descrq)tion of the regular expression that e;q>Iains 
what it is abont. 


validexanxple 


An valid example of an entry. 


errortext 


Text to be displayed when an entry does not 
conform to the pattern 


regextest 


Contains the information necessary to perform tests 
and quality assurance against the pattern. 


testvalue 


A value that is to be tested/evaluated against the 
current regular expression to determine validity. 


expectedresult 


True when one expects the testvalne to be a valid 
entry, false when one expects the testvalue to be not 
valid. 


8. Select Query 


Element/Attribute 


I>escription 


sdectquery 


The sdectquery itself . Root element. 


conn 


The name of the connection to use. This is m^f^ped 
to a connection file, specifically to a Microsoft Data 
Link file with the extension UDL 


type 


The type of query. This is the same as ADO's 
CommandTypeBaum. The possible values are: 

1 - Text 

2 - Table 

4 - Stored Procedure 

8 - Unknown 

256-File 

512 - TableDirect 


commandtimeout 


Number of seconds until this command times out 


description 


description of this select query 


parameters 


Container of parameter elements 
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paramet^ 


Constitutes the one parameter that can be passed at 
runtime to modiiy the query text. 


id 


unique parameter name identifying this parameter 


description 


description of this parameter 


datatype 


The data type of this parameter 


min 


The minimum value for this parameter 


max 


The maxunum value for this parameter 


example 


An example for a value passed to this parameter 


autofonnat 


Specifies whether or not the parameter should be 
autofonnatted, i.e, stripped of leading and trailmg 
white spaces and that single quotes be replaced with 
2 smgle quotes. 


textnode 


is not an element but is mentioned here because in 
this case more than one textnode may be used. This 
contains the actual query text, e.g. "Select * from 
authors*" 


reQ)arameter 


a reference to a defined parameter, that shall be 
replaced at runtime with the passed value 


id 


the id of the parameter 


9. Execute Select Queiy (ValSclect) 


Element/Attribute 


Description 


executeselectquery 


The executequery itself . Root element. 


lcx:ation 


Pull path to tiie FOLDER where the query definition 
file resides (Note that the UDL connection file 
required for the query must also reside there) 


name 


Name of the query definition file (without the 
extension) 


cursortype 


ADO cursor type. Defaults to forward-only (0) 


parameter 


Each parameter needed for the query is in its own 
element 


name 


Name (id) of the parameter 


value 


Value of the parameter 


10. Ten5>lates 


Element/Attribute 


Description 


templates 


Root element. 


temidate 


Element describing a particular template 


name 


Name of the template, e.g. "SMC Look** 


path 


Full padi to the folder where the template resides, 
e.g. "cAtemplatesVsmclook" 


11. Template 


Element/ Attribute 


Description 


template 


The template itself . Root element. 


parameters 


Element containing parameters. 



-33- 



BNSDOCID: «W0 OI37170»3.I*> 



SUBSTITUTE SHEET (RULE 26) 



wo 01/37170 



PCT/USOO/31221 



param^er 


Element describing one parameter. 


id 


Attribute that idendfies a pardcular parameter. 


question 


Attribute containing the question the user is asked to 
describe this parameter, e.g. "Does this form have a 
banner logo image?" 


type 


The type of parameter - text, boolean or list 


listitem 


If the parameter has a list of items associated with it. 


show 


The text to be displayed as one entry. 


value 


The internal value stored 


templateitems 


This element contains all the template items that are 
to be copied 


templatdtem 


Each item of the template 


id 


The identifier for the tenoplate item - the name of 
the file, e.g. "CS.asp- 


scanforparameters 


Boolean attribute set to true if th^e are parameters 
to be replaced by values specified by the user. 


keepname 


Boolean value specifying whether to change the 
nameof the item. 


subfolder 


The name of the subfolder where the item resides (if 
the item is in a subfolder) 


aHowoverwrite 


Boolean value specifying if the destmation file 
should be overwritten if one aheady exists. 


12. Publisfafolders 


Element/Attribute 


Description 


publishfolders 


The publishfolders root element. 


folder 


The element describing one publishing folder 


name 


Descriptive name of the folder e.g. "SMC Internal 
Forms" 


path 


Pull path to the folder, e.g. 
"c:\inetpub\wwwroot\smcuitforms*' 


urlreladvetowebserverroot 


The url of the publishing destination folder relative 
to the root of the webserver, for exanq)le if the full 
url to the publishing folder is: 
http://www.somepIace.com/SomeRoot/SomeSub/Ta 




rget 




The in-lrelativetowebservOToot attribute vahie will 
be: 

SomeRoot/SomeSub/Target 




13. IDE Configuration 


Element/Attribute 


Description 


ideconfig 


The IDE configuration root element. 


idecomponents 


The root element for all of the IDE components 


idecompoamt 


One single IDE component, which may have one or 
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more business components on which it is dq>endent 
on 


progid 


The program ID of the IDE component, e.g. 
WTKIDECQueries.CIDEQueries 


businesscomponent 


Child of ideconqwnent, referencing a busmess 
component as defined under "businesscomponents** 


progid 


The program ID of the business component. 


config 


Child of idecomponent. Allows custom subelements 
which include configuration settings for a IDE 
component, such as display preferences. 


busmesscomponents 


The root element for the business components 


busmesscomponent 


Child of business component, defines a business 
conqxjnent, which may be used by one or more GUI 
components. 


progid 


The program ID of the business component. 


busfnesscomponait 


A child of business conq)onent, indicating a 
dependant business component. 


progid 


The program ID of the dependant business 
component 


config 


Child of businesscomponent. Allows custom 
subelmients which include configuration settings for 
a business component, such as path settings. 


14. XML Selector 


Element/ Attribute 


Description 


selector 


Root elem^ that defines, just a container of regex 
elements 


Actionsetid 


ID of the Actionset to execute if the required XSL 
patterns match the XML document. 


inatchall 


If true then all of the XSL patterns have to be 
successful, if &lse then only one pattern needs to 
match. 


priority 


A number specifying how to deal with the Actionset 
if the patterns s^ply. The lower the number the 
greater the priority. Actionsets with higher priorities 
are executed first. 


pattern 


Only contains a text node, tiiat contains the XSL 
pattern that selects one more nodes firom the XML 
document. 


15. Actionset 


Element/Attribute 


Description 


Actionset 


Root element that contains the references to the 
actions to execute on an XML document. 


action 


Single action that is to be executed on an XML 
document. 


progid 


The program id of the eAgent that deals with fliis 
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action. 


acdonid 


The id of the action to execute 


16, Action Queiy 


Element/Attribute 


Description 




luc acuuiK|ucry iiscu. xvool eicnzeui. 


conn 


iiic name ui lqc connecuou lo use* ims is mappea 
w o vuiuipwuuii iucy spccuicaiiy VO a lYUCrOSOTl JL/aia 
T inV fil^ with flip i^YtAnciAit TfTlT 


type 


The type of query. This is the same as ADO's 
^uxuiuaiiu ly pcjuuuin, me possiuic values arc. 

1 - TpTt 
X ICAl 

5{ — TTtilmnwti 
o Vp/mviivVYXi 

256 - File 

512 - TableDirect 


commandtimeout 


Number of seconds until this command times out 


description 


description of this select query 






parameter 


Constitutes the one parameter that can be passed at 
runtime to modify the query text. 


lU 


iinimi^ noTQTnAfAT TiQTnA i^Afitt'fvittrT f'Viic nat'amAl'A'r 
UXUijUC polAUidCj JUdlllC zUCUUiyiUg Uila piuaiiictcr 


description 


description of this parameter 


datatype 


The data type of this parameter 


min 


The minimum value for this parameter 


uiaA 


1 ne maAUDuin voxue lor luis paToineier 


example 


An example for a value passed to this parameter 


aUlOiUixual 


d|7ccuies wncuicr or noi me parameier snouiu dc 
autoformatted i e strinned of leading and trailinp 
white spaces and that single quotes be replaced with 
2 single quotes. 


Statement 


Unlike a select query an action query may contain 
more than one statement, that's why there is an 
explicit statement element. 


textnode 


is not an element but is mentioned here because in 
this case more than one textnode may be used- This 
contains the actual query text, e.g* **delete * from 
authors" 


reft)arameter 


a reference to a defined parameter, that shall be 
replaced at runtime with the passed value 


id 


the id of die paramo 



Form Temi^tes-Purpose 
5 The purpose of form templates is to have a separate repository for the look and feel of 

the HTML pages in which the forms will be displayed. I 
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Sample Folder Structure 

^mflibrary 



5 " templates 

ten^lates.xml 



- images 



10 



15 



20 



- ssscript 
-csscrq)t 



- SMCLook 

Mam.asp (required file» must be there and must have th^ name) 
CS.ASP 
SSASP 

25 tenqplate.xml (required file, must be th^e and must have that name) 



- SmcSciDisplay 
pagebaimer.htm (in the exantple below, this one gets copied) 
30 smclogo.gif (in the example below, dtis one does not get copied, because there is no 

<tenq)lateitem. for it) 

Note: SMCLogo.gif could be in the images folder, but that's up to the tenoplates designer 
35 Templates.xml 
<ten9>lates> 

<ten5>late name= "SMC Look" folder= "c:\tenq)lates\smclook"/> 
<template name= "NIH Look" fblder= "c:\templates\nihlook"/> 
40 < /templates > 

Templatcxml 

< template > 
45 <parameters> 

<parameter id= "formcontact" question "Please aiter the eMail address for the form 
contact" type="text7> 

< parameter id= "showpictures" question = "Do you wish to show pictures for this 
form?" type="boolean"/> 
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<paramecer id— "colorscheme* question^ "Please select the color scheme you wish to 
choose" type = "list" > 

< listitem iiaine=s ^'golden" value= " 1 "/ > 
< listitem name = "green*' value= "2" </ > 
5 < /parameter > 

< /parameters > 
<teiiq)lateiteins> 

<tenq)lateitem id="CS.ASP" scanforparameters="true" keepname= "false" 
subfolder^"" aliowoverwrite- "false"/ > 
10 < templateitem id = "pagebanner.htm'' scanforparameters = "false" 

subfolder="SmcSciDispIay" keq)name="tnje" anowoverwrite="false'*/> 

< templateitem id= "pathsettingsjs.asp" scanforparameters- "true" 
folder = "LocalServerSideScript" keqpname = "true" 



15 allowoverwrite= "fidse"/ > 
< /templateitems > 
</teniplate> 



Note: 

20 - Main. ASP must exist and will be renamed accordiag to the name chosen by the forms 
designer/publisher. 

- Per the definition used in this context, a teaq>lateitem is one diat needs to be copied. 

- All templateitems must reside inside or below the template folder. 

25 Note: 

- The name of the schema mtist be provided by the publishing wizard (no user input necessary) 

- The name of the publishingfolder, where the ASP pages will be copied to, is provided by the 
publish.ASP page, (the publishingfolder is the one where main.asp and all other relevant 
items will be copied to) 

30 - name of the template is provided by user (earlier on) 

- The name of the resulting ASP page / form (e.g. Leave. ASP) is provided by the end user. It 
does not however have to be put into the template, because this is always needed. 

Publishing Process 

35 

The publishing process was previously described in detail in relation to Fig. 5. The following 
material supplements that description. 

Initiation 

40 1 . First, the user saves the form. The user will be pronq)ted to start the publishing 
wizard. If yes is selected then the wizard is started. 
2. User selects the form and chooses "publish to web." 

List of publishing folders 

45 

Per "publish.asp" there shall be one XML file that lists all available publishing folders. It 
should look as follows: , 



< folders > 
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<folder name= "General Forms" patli= "c:\inetpub\wwwroot\generalfonns 
<foWer name^-HR Forms'* path="c:\ine^ub\wwwToot\hrforms"/> 
< /folders > 

5 Commmucation between VB viizard and publish.asp 

Step 1: Present list of templates to user. User selects one. 

Step 2: If there are any parameters, present corresponding questions and let user enter them 
one by one. 

10 Step 3: If there is more than one publishing folder, present list of publishing folders. 
Step 4; Display name of the resulting form. (Default to name of schema). User clicks 
Publish. 

Note: the path to "publish.asp" is set in the config file and can also be called a different nan^. 
15 Examjde Operations 

1. Get a list of templates: 
<request> 

< action > G^TemplatesList < /action > 
20 </request> 

< response > 

<teiiq)lates> 

< template name='*SMC Loolc7> 
25 < teiiq)late name= "NIH Look"/ > 

< /templates > 
</response> 

Note: the folder attribute should not be sent to the client to hide this information (e.g. use 
30 database later on instead of folders) 

2. Get parameters for specific template and the list of publishing folders 

< request > 

35 ■ < action >GetParametersAndPublishingFolders</action> 

< parameter > NIHLook < /parameter > 
< /request > 

< response > 

40 < parameters > 

< parameter id= "formcontact" question =! "Please enter the eMail address for 
the form contact** type="text"/> 

<parameter id= "showpictures" question^ "Do you wish to show pictures for 
this form?'' type= "boolean"/ > 
45 <parameter id= "colorscheme" question'^ "Please select the color scheme you wish to 

choose" type= "list" > 

<listitem show = "golden"/ > 

< listitem show= "red"/ > 
< /parameter > 
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< /parameters > 

< folders > 

< folder name= "General Forms"/ > 

< folder name "HR Forms"/ > 
< /folders > 

</respoiise> 

3. 

< request > 

< action > formexists < /action > 

< publishingfolder > General Forms < /publishingfolder > 

< formname > Leave < /fonmsame > 
< /request > 

if form exists 

< response > true < / response > 
else 

< response > false < /response > 
4. 

< request > 

< action > publish < /action > 

< template > NihLook < /tenq>late > 

< fonnschemaname > Leave < formschemaname > 

< publishingfolder > General Forms < /publishingfolder > 

< formtitle > Leave Application < /fonntide > 

< formschemaname > Leave < /formschemaname > 

< parameters > 

< parameter id = "formcontact" > Sanjeev@Science- 
Management.com</parameter> 

< parameter id = showpictures > true < /parameter > 
<parameter id=: "colorscheme'' > golden < /parameter > 

< /parameters > 
< /request > 

if successful: 
<response/> 

else; 

<exception id= "15" >couId not access file c:... < /exception > 
Processing 

In a preferred embodiment, the processing is implemented right away in a ^chronous 
manner. However, this will not always be the case, e.g., when the publishing needs to be 
reviewed and approved before it may be published. In this case it would first get passed to the 
authorizing person, and only when approved would the actual publishing be performed. 
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To eoable easy switching to a disconnected processing, all of the data that is required 
for the actual processing of the publication is put into one XML document and passed to a 
"publish" function. This will allow the publishing process to remain identical when there is a 
switch to asynchronous processing. 
5 The processing that then takes place first scans and then copies the "Main.ASP** file, 

and then any other teniplateitems, and creates subfolders as needed. 

Each publication is joumalled as part of the processing, so that this can be used later 
for evaluation, tracking and other purposes* The joumaling should preferably inchide all of 
the information regarding a publication. 
10 Sample ASP page 

<html> 
<% 

bhiShowKctures = <repiacemeid="showpictures"></repIaceme> 
15 IfblnShowKcturesThen 

%> 

<img. 

<% 

Else 

20 .%> 



For questions please contact < replaceme id= "formcontact" > < /replaceme > 
</html> 

25 

Absolute vs. Relative Paths 

The template designer uses an "iHnclude file=.." for template items that get copied 
(and uses a relative path settmg for this), and uses a "'^mclude vutual= . . " for files that not to 
30 be copied. 

Sunilarly, for images one would use an absolute path if they are to remain in the 
template folder. However, care has to be taken not to hardwire the actual web server path, as 
otherwise one would have to change several settings if one wanted to move from one server to 
another, such as for debugging, histead, one should use the. WEBSERVERPATH variable that 
35 is set in pathsettingsjs.asp 

An exanq)le of an absolute path: 

< fang src= " < % -WEBSERVERPATH % > / mflihrary/unages/logos/nihlogo.gir alt 
widfli=:"yO" height^^lOS" align="top"> 

40 

An example of a relative path: 

<ungsrc = "../iniages/logos/nihlogo,gir alt width-"110" height="l03" align="top"> 
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Note: the same applies to other files with a source attribute, such as Script. 

The present invention is a unique product, which includes a rich Integrated Development 
5 Environment (IDE), and a powerful runtime environmrait The invention allows users to 
create powerful web based applications using, by way of example, a 4GL Rapid Application 
Development (RAD) environment. The invention is unique in a variety of important aspects 
which include the foflowiug: 

• One aspect is a hierarchical graphical user interface (GUI) that focuses on content instead 
10 of on presentation, unlike other tools of this kind, which focus on layout and presentation 

and are therefore far more time consuming. Such other tools are far more time-consuming 
to maintain for the same reason. 

• One aspect of the invention is the ease of creation AND maintenance of applications, and 
allows for easy reuse of form pages/sections/elements metadata, and presentation 

IS information as well as easy maintenance of these items. 

• One aspect of the invention focuses on con5>lete separation of tiers in every aspect of the 
product. This is done to enable independent creation and maintenance of distmctly separate 
parts of an plication. It allows non-technical people to develop the metadata of web 
based applications, leaving a minimal amount of work for the web developers (templates 

20 and regular ejqpressions) and the database develc^rs (database queries). 

For this aspect^ each of the following is stored m a different XML document and is 
accessed from different tools in the IDE. Each can therefore be performed by different 
people, and can be maintained separately: 

• the database configuration information 
25 • the database queries 

• the application presentation templates 

• the application metadata 

• the field validation code 

• custom input patterns/masks for composite fields 

30 • The invention does not require the use of a specialized •viewer* by users of applications 
developed using the inventioa. The only 'viewer' required is a standard browser. 

• The invention uses two different presentations of the same metadata to support XML- 
enabled browsers and non-XML-enabled browsers without any additional development 
effort by users of ttie program. XML-enabled browsers perform most processing on the 

35 client and, due to less roundtrips to the server, have greatly improved response times. 
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• The invention uses a queue-based n-tier architecture to increase scalability and reliability. 

• The invention uses the eAgent Architecture on the back end to perform multiple scalable 
and customizable actions aiMi work flows using data obtaiiied from the Invention 
applications. 

5 • 

The following lists more details of the variety of new aspects of the present mvention. 

1) Integrated Developmient Environment 

The Inventive Integrated Develqmxent Environment (IDE) allows users to quickly 
10 create and maintain web-based applications. The IDE uses a Microsoft Management Console- 
style interface in one embodiment with a tree view representing the form applications, queries, 
regular CTipressions and eAg^ts. 

a) Architecture 

The IDE architecture is unique. 
15 i) The User Interface configuration for individual users is stored in an XML file. 

This information specifies which parts of the IDE to load at run time {for example, the 

configuration file can specify that only the Forms designer part of the IDE should be 

loaded, and leaving the Regular Expression, Queries, and eAgent sections out of the 

IDE for that user. 

20 ii) Substantially only Form schema is stored in a unique XML file 

• Separating these form schema files from ten^late files makes applications far 
more maintainable. 

• The design stores substantially only the metadata/schema in the XML file used 
to represent the form. The presentation data is separately stored in a 

25 combination of CSS (cascading style sheet), XSL, and ASP fdes. ASP files 

are used to store the 'templates' of one or more forms, and these templates 
form the surrounding graphical presentation of the form. To represent the 
form fields, CSS files and XSL files are used to convert the XML metadata to 
HTML for presentation.. The advantage of this is that it is very easy to change 

30 the entire look and feel of a form. This can be done without touching the 

XML metadata file, 
b) Graphic User Interface 

i) The IDE runs over the web or a network - i*e. users can develop forms 
remotely. 
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ii) The IDE determines which coiiqx>nents of the IDE should be loaded at nmtunc. 
This is based on an XML configuration file. This allows for different versions of the IDE to. 
be created and deployed very easily. It also allows organizations to give some people access to 
only some aspects of the IDE. Some of these versions may not include parts of the IDE - for 
example, the following can be included or excluded: 

• Forms (the Forms designer) 

• Regular E^qyressions (validation code) 

• Queries (database select queries used to populate form lists) 

• Actions (eAgent actions such as entailing form data and inserting data into the 
database 

• Action Queries (database action qumes such as insert, update and delete) to be 
used from the Actions/eAgent section 

lii) A method is provided to create a form using a hierarchy of icons with attributes. 

Each form/application is represented as an icon wi& attributes. The attributes 
allow the user to specify the following: 

• Where to store the form on the server 

• What to name the form 

• What cation the form should have 

• Which page to submit the fonn data to. 

• Which gr^hical template to use when displaying the form. 

• Help text to appear on the form. 

• Each form page is represented as an icon one level below the form icon in the 
IDE tree view. The page attributes allow the user to specify the following: 

• The name and caption of Ae page 

• The order of the page (1** m the list, 2"* etc.) with respect to other pages 
in the form application 

• Help text to appear on this page. 

• Each page section is represented as an icon under the page icon. The section 
attributes allow the user to specify the following: 

• The name and cation of the section 

• The order of the section (1^2"**, etc.) in the current page 

• The help text to appear on this section 

• Section level validation. 
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Each section element is represented as an icon under the section icon. The 
section element attributes allow the user to specify the following: 
the location of the element within the section 
element's name and cation 

a valid eicample of what a user can fill m for this element 
the maximum length of this element 
whether this element has a list or not 
a default value for this element 
help text for this element 

whether the element is required (must the user complete this element in 
order to submit the form?) 
the data type of the element (int. float, etc.) 

The capitalization of the element value (all upper case, all lower case, 
proper case) 

the minimum and maximum values for this element 
the name of the Regular Expression used to validate user input. Also, 
Regular Expressions are kept m separate XML metadata/schema files. 
However, during form creation, the actual regular expression is inserted 
into the form n^tadata/schema. 
Simple comparison validation to other fields 
Advanced con^arison using ECMAScript (JavaScript) 
if the control used for this form is a list, whether the list comes form the 
database or not 

if the list comes from the database, the name of the query used, 
database queries are used to populate dynamic puU-down menu choices 
on the form. The database queries are stored in the metadata/schema 
that describes the form. Database queries are defined in a separate 
section of the IDE and stored in separate XML files, 
database queries can be pre-processed (run at design time) - i.e. the 
results stored in the metadata/schema document that describes the form. 
The control type used for this element 

If the list is not populated from the database, the list values to be used 
for this list. 
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• Whether the control used for this element shoiild be displayed on a new 
row or not. 

• The width of the control used to display the element 

• Whether the control used should wrap to the next line 

• The type of control which should be used 

• If the control is a list, wheflier the list should be nuiltiselect 
» If the control is a list, the prompt to use in the list 

• If the control is a text area, the number of rows and columns to be used. 

iv) A method is provided to publish forms to the web using a wizard which lists 
predefined tmqplates and allows a user to select a template for the form, as well as a folder 
location for the form. The basic task of the publishing wizard is to create ASP pages and 
assodated files in a publishing folder that associates/links a form schema with a tenq>late. 
Ten:q>late files may have custom parametm/questions that are displayed inside die publishing 
wizard whidi allows for flexible on-the fly customization of ten^lates just by answermg the 
questions inside the publishing wizard. 

v) A method is provided to save, create, test and retrieve regular expressions using 
XML files for storage and retrieval. 

• Regular expressions are represented as icons in the GUI 

• Each Regular Expression may be a set of ASCII characters that describes 
valid inputs 

• The IDE helps users create Regular Expressions 

• The IDE helps users test Regular Expressions 

• The IDE allows users to import Regular Expressions from an outside data 
file 

• This will allow the sales of Regular Expressions on the Web or network 
and their seamless mcorporation mto the IDE. 

vi) A method is provided to save, create and test database queries 

• Database queries may t>e represented as icons in the GUI 

• Each Database Query is a custom SQL query that is able to interact with 
relational databases. 

• Database connections are described separately - allowing the Database 
Query to be directed at multiple databases. (The database could be MS 
Access, MS SQL Server, Oracle, or other database - the user does not 
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need to specify beforehand and can switch at any time without affecting the 
fbnn,) 

• This gives users the ability to change the database used for a project 
without having to change the form metadata/schraia at all. 

vii) A method is provided to store and retrieve form elements and form sections in a 
library. For exanqple: 

• A Library of Sections and Fields 

• A library from wbidi users can drag and drop form sections and form 
fields into the form they are currently creating 

• LINKED sections and fields will retain the properties described in the 
library - then, to make a universal change to a field common to many 
forms, one change in the library will be reflected in all forms. This 
provides the ability to make a change to a section or form that (optionally) 
automatically changes all related q)plications in the users' web site. 

• COPIED sections and fields will not retain the properties described in the 
library and are customizable for each form. Subsequent changes in die 
library (such as specifying a different database source) will not be reflected 
in all forms, but oidy forms that are linked to the library. Users can add 
any section, or field to the library at any time. 

2) Invention Runtime Ekivironment 

The Invention Runtime Environment is a highly scalable, maintainable, and reliable runtime 
environment that uses data created using the DDE or by other means to serve sophisticated web 
based applications to users with both XML-compadble and non-XML-conq[)atible browsers, 
a) Runtime Environment Architecture 

The Invention runtime environment is unique and includes a variety of aspects 
including: 

i) A method to serve two or more distinct versions of the form/application using 
only one form/application description file. 

• In one aspect, the design automatically creates and maintains two versions 
of each application using only one form in the IDE. This means that users 
of the IDE need only maintain one version of the form/^plication, but: 
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users of XML-coixq)atible browsers are served a quick, efficient, 
client-side version of the form, which reduces web server load and 
increases clirat-iside performance. This version inchides sending 
the schema XML ffle, and any XSL files, CSS files, and JavaScript 
files for navigation and validation to the browser for processing. 

Users of non-XML-compatible browsers are served a pure 
HTML/CSS version of the form pages which processes each page 
in die form on the server. This version involves processing the 
XML schema file, and any XSL files, JavaScript files and COM 
10 components on the server, and sending html and CSS to the 

browser, 

A method is provided (folder architecture) to store web files for ultimate ease of 
maintainability and reuse of ^plication. An important aspect is the fact that the final form 
files can have minimal size (less than 10 lines) because of the fact that they only have the 

15 values that differentiate them from other forms and LINKS to bofli a forai schema and a 
template. What makes this possible is the combination of a standardized folder structure with 
Server-Side Includes (SSI) that use absolute paths. SSI are a programmatic construct of Active 
Server Pages that allow the inclusion of content from another file into the existing file at the 
server. The advantage of this approach is the ability to change both the schema and the look 

20 and feel independently both at the time of creation and after the form has been published. 
There is no need to republish the form for ttiese changes take effect; they take immediate 
effect. Also, there is a n:m relationship between a tenoplate and a schema, i.e., one template 
can be used with multiple schamas and one schema can be used with nniltiple templates. This 
allows for maximum reuse. 

25 A company can have a standardized look and feel defined for all its fonns or a subset of them, 
and easily associate schemas with this tornplate. If the conqjany wishes to change the 
standardized look and feel, e.g. , die name and logo of the company changed, the change has to 
be done only in the template and takes inmiediate effect for all the forms that are associated 
with this ten:q)late. 

30 Reuse of schmas: 

An application service provider (ASP), in one aspect, may develop and sell a set of 
standardized schemas for work processes. Several companies/customers may wish to use these 
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Standardized schaooas, however they may wish to have their own look and feel with the 
schemas. The ASP provides customized tecoplates for each customer, and associates the 
resulting forms with the customized templates and the standard schemas. If there is a need to 
change the schema, e.g., another field is required, then the ASP only needs to change the 
5 standardized schema and the change takes immediate effect for all forms that link to this 
standardized schema. 
eAgent Architecture 

A further aspect of the invention is the eAgent architecture. It uses a set of COM components 
10 and configurable XML files in a preferred embodiment to determine ^propriate actions, and 
to perform these actions for each XML document received in the queue system. Some of the 
ino^rtant aspects include: 

i) Pattern-content based selection of actions to be performed - an eAgent manager 
determines which Actionset to perform by searching each incoming XML document for 

15 previously cached XSL patterns. Using XSL patterns, a component (the eAgent Manager) 
determines the type of each incoming XML document, and determines which Actionset to 
perform based on the type of XML document involved. The component knows which patterns 
to search for based on the cached XML selector documents. 

ii) A hot-{)luggable eAgent conqwnent architecture: An architecture in which 
20 'action' components can be added without having to recompile any code, stop and restart any 

services, or interrupt the functionality in any way. More eAgents (with corresponding action 
files) can be added to the system at any time without interruption. All that is needed is that 
any Actionset file which will utilize the new eAgent be updated with the new ProgID of the 
eAgent, and which actions to perform. Since Actionset files are XML documents, this does 
25 not require the stopping and starting or recotiq)iling of any code or code components. 

iii) A business rules system which is changeable at run-time (without interrupting 
normal operation) - the eAgent architecture includes several components that implement the 
system business rules or work flow. These are the eAgent Manager, the eAgent Action 
Coordiuator, and the eAgents, in a tiered architecture. However, the business rules themselves 

30 are defined in XML documents which can be changed without recompiling any code, and in 
fact can be changed during run-time. (Prior art systems typically would at the very least 
require the system to be stopped and restarted, and in many cases a complete recompile of the 
code would be required). 
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iv) A decoupled acdon set system: The eAgeats in the system are self aware only. 
They are not aware of the existence in the system of other eAgents. Despite this, actions can 
be performed which transfer infonnation from one eAgait to another. This is done as follows: 
The eAgent Action Coordmator calls an eAgent function and passes the eAgent 
a copy of the routing document^ which incorporates both the incoming XML 
document and the results of execution from previous eAgents, It receives back 
the result of the processing as an XML document/element, which it adds to a 
routing document attached to tiie original XML document, before passing the 
original XML document and the routing document to the next eAgent specified 
in the Actionset. Another advantage of ttiis is that there is no possibility for an 
eAgent to corrupt the original message. But more importantly, eAgents need 
not be designed to work in tandem with any other code or componmts other 
than die eAgent Action Coordmator. 

Spedfie eAgmts 

The curr^ miplementation of the invention employs several eAgents: 
ActioH'&ieiy eAgent: 

The Acdon-Query eAgent allows the system to insert, update and delete data in 
any ODBC and/or OLE DB compatible database. The data from the inconndng 
XML document can be mapped to fields in the database tables. The mapping is 
defined in Action-Query documents and the eAgent uses this and the incoming 
XML document to insert, update and/or delete data in the database. 

Schema eAgent: 

The schema eAgent allows the system to automatically create and update 
database tables axui action queries based on the incoming XML document. Using . 
this automation facility radically simplifies the development of XML to database 
mapping. 

PDF eAgent: 

The PDF eAgent populates an empty PDF form template with data from the 
incommg XML document. The PDF eAgent action document defines the 
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teniplate to use and othw relevant parameters. A nanung convention is used to 
map the information from the incoming XML document to the fields inside the 
PDF form template. 

eMail eAgent: 

The eMail eAgent allows the system to send eMails to multiple recipients with a 
subject, a body, and zero or more attachments. The eMail eAgent action 
document constitutes the template for the eMail, and is used in coordination 
wi& the incoming XML document to construct the eMail. 

Script eAgent: 

The script eAgent allows an ActiveScript, such as one written in VBScript, 
JavaScript or Perl, to perform any action on the incoming XML document. As 
these scripts have access to COM conq>onents on the system, including the 
database, file system* eMail and other conqwnents, these scripts offer an 
enormous amount of flexibility. The access to the incoming XML document is 
simplified by providing an object model for the script to use. 

Sample workflow (simplified): 

Business Task 

The time for processing of "request for leave" forms must be improved. The 
HR manager wants to be immediately notified of new requests for leave. S/he 
also wants a database of all requests so s/he can view leave-related reports. In 
addition, di2e to company policies, s/he also needs the requests in writing, 
signed by die person requesting the leave. Ideally, the data should only be 
entered once. 

Technical Implementation 

The form "Request For Leave** is filled out in the browser by the person 
requesting the leave. When the user submits his/her request the request for leave 
application (XML document) is submitted to a queue. The queue manager 42 
picks it up from the queue and passes it on to the eAgent manager 44, which 
determines the corresponding Actionset. The Actionset encompasses four 
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actions: 

The first action is passed to the Action-Query eAgent with the document ID of 
**insertLcave''. The Action-Qu^ eAgent reads the action document and then 
inserts the relevant data from the XML document into the database and returns 
execution to the eAgent Action Coordinator 46, indicating that it has 
successfully completed it's task. In this way, all requests are recorded in a 
database which can be utilized for analysis and reporting purposes. 

The eAgent Action Coordinator 46 then calls the PDF eAgent with the "leave'* 
action ID, The PDF eAgent reads the action document, finds the location and 
parameters of the PDF form template and using a naming convention, fills all 
fields in &e template with the corresponding parts of the XML document and 
saves the resuldng PDF document. In addition to retoming a success code, it 
documents the location of this PDF document in the routing document for later 
use. 

The third action involves sending the person who submitted the leave request an 
eMail with the PDF document as an attachment that was created in the previous 
action. For this the eMail eAgent is called with the **IeaveAck*' action document 
ID. The eMail eAgent loads this action document and constructs an eMail, 
which contains the person who submitted the leave request as a recipient and 
contains the PDF form as an attachment. The eMail eAgent then sends this 
eMail to the person requesting the leave. To fulfill the current concpany 
regulations, that person can then print out the PDF form, sign it and pass it on 
to the HR department. There is no need to enter the data a second time. The 
eAgent returns a success code to the eAgent Action coordinator 46. 

The fourth action involves sending the HR manager an eMail, The eMail eAgent 
is called by die eAgent Action Coordinator 46 with the "leaveHR" action 
document ID. The eMail eAgent reads the action document and constructs and 
sends the eMail to the HR manager. 

Additional e-commerce aspects 

Faced with today's new, rapidly expanding marketplace, e-comraerce merchants have 
found themselves unable to efficiently and effectively communicate their orders to suppliers 
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and unable to obtain vital business process information* such as real-time inventory levels. Up 
until now, it has been extremely difficult for conqianies to conduct business over the Internet 
because of the lack of a single technical vocabulary for describing busmess processes. 

The only widely adopted e-commerce transaction solution today, Electronic Data 
5 Interchange (EDI), has fostered a fragmented market, where trading partners have created 
"islands of standardization" which support only specific vendors and implementations. Each 
mterconnection must be carefully majjped from a source system to the receiving system and 
maintained individually as source and receiving systems evolve. Each new trading partner 
adds to the staggering number of unique combinations which must be individually strucnired 
10 and maintamed— resulting in global technical gridlock. 

EDFs high costs, low ROI and limited services have restricted its market penetration to 
less than 2% of all US businesses. 

Online Transaction Oearinghouse Solution 

The eAgent tiered configuration, described as one aspect of the present Invention, 
15 possesses the unique capability to provide an unlimited volume and variety of lowest-cost 
transactions between any vendor and any supplier, Qirough an online transaction clearinghouse. 

Based on open Internet technologies and standards, mcluding XML, this aspect of the 
present invention fulfills a specific niche that has not, until now, been successfully addressed. 
Using multiple, geogrq>hically-dispersed high-c^acity servers, this aspect of the invention 
20 aUows the receipt and processing of intelligent busmess-to-business (b2b) transaction and 
workflow instructions, including purchase orders, payment and fulfillment instructions, and 
price and inventory requests. 

This aspect of the present invention facilitates seamlessly integrating all transactions, 
and will guarantee the distribution of correct transaction instructions, regardless of the ERP 
25 systems; legacy systems, or databases used by suppliers and merchants involved in the 
transaction. The online transaction clearinghouse facilitated by the present invention is a 
complete supply-side transaction solution designed to maximize accessibility, reliability, 
responsive service and speed of fulfillment. 

Each transaction m accordance with this aspect of the present invention relies on the 
30 following services, each of which may be contained within the Forms Web site: 

1. The Guaranteed Transaction. E-commerce Web sites and/or Forms web sites will send 
secure, XML-formatted transactions to a global array of Message Queue (MQ) Servers, all 
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poised to capture each e-conimerce transaction and forward it to the closest facility. If one 
MQ Server goes off-line, any of the others will step in to seamlessly take its place. 

2. The Business Rules Package. The E*conunerce Web site' transaction instructions and 
Forms environment will contain business rules, in addition to the basic transaction that will 
be executed using the described eAgent workflow engine. 
Hie e^ent. 

This aspect of the Invention will use the eAgent architecture to transfer orders and data 
requests (such as status of order) to a merchant's back-end system aixJ receive information, as 
appropriate. 

This e<ommerce aspect of the present Invention is the only solution to fully address all 
four major sources of transaction costs: 

1. The asynchronous systems architecture and intelligent eAgent technology of this e- 
commwce aspect of the invention together provide an unlimited edacity to receive, 
store and process information. This unique combmation of capabilities engenders near- 
zero marginal quantitative and qualitative costs of new transactions. 

2. This e-cGwmstcc aspect of the Invention assures transaction reliability, on-time payment 
and low charge-back rates. 

3. This e-commerce aspect of the present invention provides timely market intelligence and 
an online adjustable 'smart' business logic vehicle, which combine to enable instant 
reactions to market fluctuations. 

4. This e-commerce aspect of the present Invention drives transaction services and buyer- 
supplier relationships toward perfect conq>etition, continually reducing the 'asset 
specificity' portion of the transaction cost. 

This e-commerce aspect of the Invention enables enterprises to create a universally 
accessible value web of increasingly complex, interlocking products and cross-selling 
arrangements. 

From flie above, it can be seen that important aspects of the present invention include: 

• Use of a tiered software architecture that does not compromise on scalability, 
maintainability and performance. 

• Ease of int^ration: The present invention offers exceptional ability to 
integrate the submitted form data with any other computer system or user by 
having schema and captured data as an XML document. 
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• Uses one metadata description of forms to display multiple outputs (client-side 
DHTML/XML/XSL, or server-side Active Server Pages (ASP), or many other 
possibilities.) 

• Simplicity. A forms designer needs to only be able to use one simple gr^hical 
5 user interfoce to create, administer and publish powerful forms to the 

Intranet/IntemeC without the need to have any know-how in the areas of 
HTML/ASP/XML/XSL/CSS/Regular Expressions/JavaScript etc. 
Using this innovative approach, the present hivention can be developed and deployed 
by non-programmers in a short period of time, and over the Internet or over a network. 
10 Changes to forms (maintenance) can be made even more quickly than form creation (again 
over the Intemet), The present invention supports all of the major browsers and is highly 
scalable, fast and maintainable. And, by having the submitted data available as XML, the 
results can be easily integrated into any other system. Before the present invention, developing 
online forms with fields, validation, a preview page, and separate versions for IE5.0 and 
15 Netscape would have taken a fiilly qualified programmer several weeks. Maintaining such an 
ai^lication would have taken die same programmer far longer. 

The foregoing descrq)tion of the preferred embodiment of the Invention has been 
presented for purpose of illustration and description. It is not mtended to be exhaustive or to 
limit the Invention to the precise form disclosed, and modifications and variations are possible 
20 in light of the above teadiings or may be acquired from practice of the invention. The 
embodiments were chosen in order to explain the principles of the Invention and its practical 
applications in order to enable one skilled in the art to utilize the Invention in various 
embodiments and with various modifications as are suited to the particular use contemplated. 
It is mtended that the scope of the Invention be defined by the claims aj^nded hereto, and 
25 their equivalents. 
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WE CLAIM: 

1. An integrated development method for creating forms, comprising the steps of: 
storing at least one schema for a form in a first file at a computing resource, wherein 

said schema comprises minimal user interface representations; 

accessing at least one template of a form in at least one second file sqjarate fi:om said 
first file, wherem each of said templates comprises a user interfiace rq)resentation of said 
form; 

selecting one of said at least one template and one of said at least one schema; and 
creating at least one linking file that links said selected schema and said selected 
template. 

2. A mediod as defined in claim 1, wherein said schema storing step coniprises the 
step of storing a plurality of differ^ schema. 

3 . A method as defined in claim 1 , wherein a plurality of different templates can be 
accessed in said template accessing step. 

4. A method as defined in claim 1, wherein said schema storing stqp conq>rises the 
step of storing a plurality of differ^t schema. 

5. A method as defined in claim 1, wherem said schema storing step comprises 
creating said schema, including the step of copying at least one element from a different 
schema into said schema being created. 

6. A method as defined in claim 1, wherein said schema storing step conq)rises the 
step of copying at least one element from a database of reusable elements to form said schema. 

7. A mediod as defined in claim 1, wherem said schotna storing step comprises the 
step of linkmg at least one element into said schema from a database of reusable elements. 

8. A method as defined m claim 7, wherein said reusable elements are fields. 

9. A method as defined in claim 7 wherein said reusable elements is a plurality of 
said fields. 

10. A method as defined in claim 7, wherein said reusable elements are queries. 
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11. A method as defined in claim 1, further comprising the step of 

creating said schema^ including the steps of selecting query information from a qnety 
information database separate firom said first and second files, and incorporating said (piery 
information into said schema. 

12. A method as defined in claim 11, wherein said query information is linked to 
said schema. 

13. A method as defined in claim 1 , further comprising the step of: 

creating said schema, including the steps of selecting a regular expression from a 
regular expression database separate from said first and second files, and incorporating said 
regular expression into said schema so as to validate inputted data. 

14. A method as defined in claim 13, wherein said selected regular e)q>ression is 
lioked into said schema. 

15. A method as defined in claim 1, further con[q)rising the step of creating said 
schema, including the steps of selecting a user-defined control from a custom database separate 
firom said first and second files, incorporating said user-defined control into said schema so as 
to provide improved ixq)ut fDr fields made up of a plurality of variable and fixed text elements. 

16. A method as defined in claim 1, wherein said schema storing step comprises the 
step of storing said schema in a data-centric hierarchical storage and retrieval mechanism. 

17. A method as defined in claim 16, wherein said data-centric hierarchical storage 
and retrieval mechanism is XML. 

18. A method as defined in claim 1, further comprising the steps of at runtune 
converting said schema to an mterface with a user. 

19. A method as defined in claim 18. wherehi said converting step comprises 
converting the schema to HTML. 

20. A method as defined in claim 15, wherein said schema includes elements with 
attributes. 

21 . A method as defined in claim 20, further comprising the step at runtime of using 
attribute based validation to validate end xi&er vop^ixt data. 
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22. A mefbod as defined in claim 21, Airtlier conq)rising the step at runtime if an 
error is discovered during said validation step> inchzding an error flag and an associated error 
message in said schema or sqparate schenoa in said data-cemric hierarchical storage and 
retrieval mechanism. 

23. A method as defined in claim 22, wherein said error message is presented to a 

user, 

24. A method as defined in claim 1, further comprising the step of: allowing the 
separate creation and modification of parts of the forms creation and maintenance process and 
thereby allowmg specialization of tasks. 

25. A method as defined m claim 24, wherein said tasks include designing queries, 
regular expressions, user-defined controls, templates and forms creation and processing of the 
submitted of data. 

26. A method as defined in claim I, wherein said schema comprises at least one 
field; and 

further conq)rising a field library separate from said first and second files for storing 
one or more fields; and 

wherein said schema storing step corqprises the steps of: 

storing in a file a schema comprising a link to said at least one field m said field 
library; and 

storing m a file a transformed schema that does not include said link to said at least 
one field, but rather contents of diat field 

27. A method as defined in claim 26, wherein said schema includes a plurality of 
said fields, and wherem said schema includes links to at least two different fields m said field 
library. 

28. A method as defined in claim 26, wherein for a field that is changed in said field 
library, updating a plurality of said schema that contain a Imk to said changed field. 

29. A method as defined m claim 28, wherein said updating step includes the steps 
of retransfbrming said schema. 
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30. A me&od as defined in claim 28, wherein said updating step comprises 
performing said updating step during runtime. 

31. A method as defined in claim 1, wherefin said linking file creating step 
comprises the steps of creating a linking file for a data-centric hierarchical storage and retrieval 
mechanism user-interface program, and creating a linking file for a non-data centric 
hierarchical storage and retrieval mechanism enabled user-interface program. 

32. A method as defined in claim 1, wherein a navigation engine can navigate 
among a phurality of sections, and wherein said schema storing step comprises a step of 
storing a schema with at least two sections. 

33. A method as defined in claim 1, further comprising the step of defining teraplate 
specific customization questions. 

34. A method as defined in claim 1, wherein said schema comprises at least one 
field; and further comprising the step of creating a schema and storing a schema includmg a 
link from said one field to a field in said field library of reusable fields; and storing a 
transformed schema with no links. 

35. A method as defined in claim 1, if a user interface program is not compatible 
with a data-centric hierarchical storage and retrieval mechanism, then creating a unique 
identifier at runtime for an instance of one said storage schemas. 

36. A method as defined in claim 35, wherein said unique identifier is passed 
between a navigation engine in said confuting resource to and from a user interface program 
at a user location. 

37. A method as defined in claim 1, wherein at runtime submitted end user data is 
written to a queue. 

38. A method as defined in claim 37, wherein a log of transactions is created for 
said queue. 

39. A method as defined in claim 1, wherein for a user interface program that is 
compatible with a data centric hierarchical storage and retrieval mechanism, at runtime 
seleaing a schema and sending said selected schema to said user interface program as an island 
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of data in accordance with said data-centric hierarchical storage and retrieval xnechamsm, 
within a form page in presentation language. 

40. A method as defined in claim 39, wherein said selected schema is in the form of 
an XML island in an HTML page. 

41. A method to publish forms con5)rismg the steps of: 
creating a schema; 

providing a list of predefined tenq)lates; 
selecting a template; 
selecting a publishing destination; and 
linking said schema to said selected template. 

42. A method as defined in claim 41, further comprising the step of re^ondmg to 
tenaplate specific customization questions and linkipg responses to said selected template. 

43. A method for creating a regular expression file conqjrising the steps of: 
inputting and presenting a name for a regular expression; 

inputting and presenting a pattern for a regular expression that is to be used in a 
validation engine; 

inputting and presenting an error n:iessage for user inputs that do not match said pattern; 

inputting at least one test case; and 

comparing said test case to said pattern; and 

presenting a message in response to said comparison step. 

44. A method as defined in claim 43, further including the step of i2q}utting and 
presenting a description of said regular e;q>ression. 

45. A method as defined in claim 43, further comprising the step of inputting and 
presenting at least one valid exaniple of said pattern. 

46. A navigation engine program product, comprising: 

a conq>uter usable medhun having computer readable program code embodied therein 
conq)rising: 

first code for transforming data-centric hierarchical storage and retrieval mechanism 
data to presentation language; 
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second code for receiving data in presentation language and converting said received 
data to said data-centric hierarchical storage and retrieval XDechanism; 
third code for performing attribute based validation on said data; 
fourth code for providing navigation among present pages; and 
fifth code for saving said data in response to a command. 

47. A computer program product as defined in claim 46, wherein said third code 
operates to perform said attribute validation only after said data has been converted to said 
data-centric hierarchical storage and retrieval mechanism by said second code. 

48. A method for processing forms on a user-interfece program, conq}rising the 
steps of 

receiving an engine and a file with a form including a schema and a template in data- 
centric hierarchical storage and retrieval mechanism; 

transforming with said engine said form from said data-centric hierarchical storage and 
retrieval medianism into presentation language and presenting said form at said user-interface 
program; 

receiving user input data in said presentation language; 

converting said user ii^nit data to said data-centric hierarchical storage and retrieval 
mechanism; 

performing attribute based validation on said converted user input data; 

incorporating any error detected in said validation step in said data-centric hierarchical 
storage and retrieval mechanism into said form schema or separate form schema; 

converting said any error into presentation language and presenting an error message 
associated therewith to said user; 

allowmg said user to correct said user input data, if necessary; and 

saving said user input data. 

49. A method as defined in claim 48, wherein said form transforming step 
comprises the step of receiving a schema as an island in the format of a data centric 
hierarchical storage and retrieval mechanism in a form page represented in presentation 
language, 

50. A method as defined in claim 49, wherein said schema is stored as an XML 
island in an HTML page. 
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51. A method as defined in 48» jfurther comprising the step ot presenting a preview 
of said form to said user with said user voput data incorporated therein. 

52. A method as defined in claim 48, further comprising the step of allowing said 
user to navigate among different sections in said form. 

53. A method as defined in claim 48» further conq)rising the step of submitting user 
data and writing said submitted user data to a queue. 

54. A method as defined in claim 53, further comprising the step of creating a log of 
transactions of said schema. 

55. A runtibtne envu-onment method for an electronic forms applications, comprising 
the steps of: 

receiving a forms request from a user-interface program; 

determining if said user-interface program is compatible or not conpatible with a data- 
centric hierarchical storage and retrieval mechanism; 

sending from a computing resource to said user-interface program, if said user-interfoce 
program is conQ>atible with said language, a schema file containing form mfonnation to be 
inserted into a form teoaplttte and a form navigation engine and a form input validation engine; 
and 

if said user-interface program is not compatible with said storage and retrieval 
mechanism, sending user input information to said computing resource for processing and 
sending a presentation language version of form pages resulting from said coiiq}uting resource 
processing back to said user-inter&ce program. 

56. A method as defined in claim 55, wherein at runtime the step is performed of 
using attributes to validate end user input data. 

57. A method as defined in claim 55, where at runtime the step is performed of 
writing results of said validation and any oror message associated therewith into said schema. 

58. A method as defined in claim 55, if a user interface program is not compatible 
with said data-centric hierarchical storage and retrieval mechanism, then creating a unique 
identifier at runtime for forms processed at said conq>uting resource. 
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59. A method as defined in claim 55, wherein said unique identifier is passed 
between a navigiation engine in said computing resource to and from said user interface 
program at a user location. 

60. A method as defined in claim 55, wherein at runtime submitted end user data is 
written to a queue. 

61. A method as defined in claim 60> whorcin a log of transactions is created for 
said queue. 

62. A method as defined in claim 55, wherein for a user interface program that is 
compatible with a data centric hierarchical storage and retrieval mechanism, at runtime 
selecting a schema and sending said selected schema to said user inter&ce program as an island 
of data in accordance with said data-centric hierarchical storage and retrieval mechanism, 
within a form page in presentation language. 

63. A method as defined in claim 62, wherein said selected schema is in the form of 
an XML island in an HTML page. 

64. A method for creating a form file comprising the steps of: 
storing an a form file a path to a schema in a first file at a storage location; 

storing in said form file a path to a template in a second file different from said first file 
at a storage location; and 

storing said form file at a user location. 

65. A method as defined in claun 64, wherein said step of storing said form file 
includes the step of storing customization mformation for a template. 

66. A method as defined in claim 64, wherein storing said form file step includes 
the step of storing customization information for a form. 

67. A method as defined in claim 64, wherein said stored paths are absolute paths. 

68. A method for performing customized actions in a computing environment, 
conqjrising the steps of: 

providing at least one selector file, each selector file containing at least one selector 
pattern and associated with an actionset that contains at least one action, wherein said at least 
one action contains at least an eAgent ID and an associated action document ID; 
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obtaining a dcxnunent for processing from a queue; 

searching said document for a match to at least one of said selector patterns of said 
selector files; 

if a match is found for one of said selector patterns, executing said at least one action in, 
said Actionset associated with said matched selector file, including loading an eAgent specified 
by said eAgent ED; and 

said eAgent reading an action document specified by said associated action document 
ID and performing an action specified therein. 

69. A mediod as defined in claim 68, further comprising the step of obtaining a 
document for processing from one of a plurality of said queues. 

70. A method as defined in claim 68, further comprising the steps of: creating a 
routing document; attaching said document to said routing document; and attaching 
information to said routing document 

71. A method as defined in claun 70, wherein said mformation attached to said 
routing document relates to a status of the action. 

72. A method as defined in claim 70, wherein said information attached to said 
routing document comprises result information from said action performed by said eAgent, 

73. A method as defined in claim 72, wherein said information is readable by a 
different eAgent. 

74. A method as defined in claun 70, wherein said information attaching step 
comprises attaching said information only from non-eAgents. 

75. A method as defined in claim 68, wherein said document is in a format of a 
data-centric hierarchical storage and retrieval mechanism. 

76. A method as defined in claim 68, wherein said document is in XML. 

77. A method as defined m clafan 68, wherein said selector file, routing document, 
Actionset and action documents are in a format of a data-centric hierarchical storage and 
retrieval mechanism. 
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78. A method as defined in claim 68, wherein said selector file, routing document, 
Actionset and action documents are in XML. 

79. A method as defined in claim 70, wherein said information attached to said 
document comprises an indication of status of said action by said eAgent. 

80. A method as defined in claim 68, further conq>rising the step of creating a 
completion f3e, wherein said routing document is stored in the format of a data-centric 
hierarchical storage and retrieval mechanism. 

81. A method as defined in claim 80, wherein said completion file is stored to a 

queue. 

82. A method as defined in claun 70, wherein said information attached to said 
routing document comprises a time stamp of at least when the acdon was conq)leted. 

83. A mediod as defmed in claim 70, further con^rising the step of determining if a 
second action is present with an associated second document ID and a second eAgent ID; 

said eAgent associated with said second eAgent ID reading an action document 
specified by said second action document ID and performing an action specified therein; 
attaching information to said routing document; and 

sending said routing document with said attached roformation to said completion file. 

84. A method as defined in claim 70, further comprising the step of determining if a 
-match to a second selector pattern in said selector files is found, and if said match to said 
second selector file is found, executing a second Actionset associated with said matched second 
selector fUe, including loading an eAgent specified by an eAgent ID in said second Actionset; 

said eAgent reading an action docummt associated with an action document ID in said 
second action set and performing an action specified dierein; and 
attaching information to said document. 

85. A method as defined in claim 68, wherein said Actionset contains another 
Actionset. 

86. A method as defined in claim 68, wherein said Actionset contains at least one 
command from a set of commands conqjrismg branching and repetition commands. 
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87. A metbod as defined in daim 68» whearein said Actionset contains a parallel 
execution conunand, 

88. A metbod as defined in claim 68, wherein said Actionset contains a time 
controlled execution command, 

89. A metbod as defined in claim 68, wberein said providing step includes providing 
a plurality of selector files, with each of said selector files containing a priority relative to 
other selector files. 

90. A system for generating forms in a coasting environment, conq>rising: 
a schema database; 

a template database separate £r<Kn said schema database; and 

at least one linkage file, each containing code to link a selected schema with a selected 
tezqplate. 

'91. A system as defined in claim 90, further comprising : a database of validation 
patterns separate firom said schema database and said tenq)late database; and a database of 
query information separate from said schema database and said ten^late database 

92. A system as defined in claim 91, further comprising a plurality of different 
forms creation modules, with each of said modules providing a different method of 
manipulating one or more of ^d databases. 

93. A system as defined in claim 91, further coroprising a forms designer 
configuration database listing which of said modules are to be used by different forms 
designers at nmthne. 

94. A system as defined in claun 92, wherein said plurality of modules mchides a 
forms Creadon modules for allowing a forms designer to create a schema with validation. 

95. A system as defined in claim 92 wherein said plurality of pzodules includes a 
forms creation module for allowing a forms designer to select' regular expressions from said 
regular expression database for use in said validation. 

96. A system as defined in claim 94, wherein said forms creation modules includes 
code to provide a link in said schema to said selected regular expression in said regular 
expression database. 
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97. A system as defined in claim 92, wherein plurality of modules includes: 

a forms creation module for allowing a forms designer to select query information from 
said query information database to create elements in said schema. 

98. A system as defined in claim 97, wherein said query selecting forms creation 
module includes code to provide a link in a schema to said selected query information in said 
query database. 

99. A system as defined in claim 97, wherein said plurality of modules includes a 
regular expressions module for allowing said forms designer to add/change regular ejg)ressions 
in said regular expressions database. 

100. A system as defined in claim 92» wherein said plurality of different forms 
creation modules includes a query information module for allowing said forms designer to 
add/diange query information in said query information database. 

101. A system as defined in claim 90, further comprising an elements database for 
storing a plurali^ of different elements that may be reused in forms. 

102. A system as defined in claim 92, further comprising an actions module for 
including code for controlling at least one eAgent. 

103. A system as defined in claim 92, further con:q)rising a custom module for 
creation of user-defined controls. 

104. A system as defined in claim 92, wherein said plurality of modules includes a 
forms creation modules for allowing a forms designer to select a user-defined control. 

105. A system for performing actions on documents in a confuting environment, 
comprising: 

a selector file database containing a plurality of selector files; 
an Actionset database containing a plurality of Actionsets; 
wherein each selector file is associated with exactly one Actionset; 
an eAgent specific action document database containing a plurality of action documents 
that are specific to eAgents; 

wherein each of said Actionsets is associated with at least one action document. 
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106. A system as defined in claim 105, further comprising at least one creation 
module for creating and/or manipulating entries in one of said databases. 

107. A system as defined in claim 105, further comprising: 

code for specifying at least one of said selector files from said selector file database; 
code for specifying at least one of said Actionsets from said Actionset database; 
code for specifying at least one of said eAgent specific action documents of said eAgent 
specific action documents; 

code for linking said specified selector file with said specified Actionset; and 
code for linking said specified Actionset with said specified action document. 

108. A con5)uter program product for an integrated development environment, 
comprising: 

a conpiter usable medium having a computer readable code embodied therein, 
comprising: 

presentadon host code, said presentation host code including shared user interface and 
logic code components, code for reading a IDE configuration^ and code for loading any IDE 
component code and business logic con^>onents code as defined in said IDE configuration; 

at least one IDE component code loaded by said presentation host on said user-interface 
program, said IDE component code including a user interface; and 

at least one business logic component code loaded by said presentation host , on said 
user*interface program, said business logic componrat code defining the interrelationships 
between objects represented in said user interface. 

109. A computer program product as defined in 108, funher including a data access 
abstraction layer code that allows business components code to read and write information 
to/from a compatxag resource. 

110. A con^uter program product as defined in claim 108, wherein said presentation 
host code runs within a browser. 

111. A computer program product as defined in clakn 109, wherein said data access 
layer access allows reading and writing information to/from a computing resource over a 
communications link. 
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112. A conq)Uter program product as defined in claim 109, wherein said data access 
layer access allows reading and writing information to/from a local computing resource. 

113. A con^mter program product as defined in claim 108, wherein said presentation 
host includes code for sharing business components code. 

1 14» A con^ter program product as defined in claim 108, wherein presentation host 
code, said IDE component code, said business component code, said data access abstraction 
layer code are each on a different tier, wherein a tier permits communication only with 
conqx>nents in the same or neighboring tiers. 

115. An integrated development environment mediod, conqirising the steps of: 
loading onto a conq>ut^ resource code in a tiered architecture comprising: 

a presentation host tier that includes presentation host code, said presentation host code 
including shared user interface and logic code components, code for reading a IDE 
configuration, and code for loading any IDE component code and business logic components 
code as defined in said IDE configuration; 

an IDE con^onent tier, including at least one IDE component code loaded by said 
presentation host on said user-iuterface program, said IDE component code including a user 
interface; 

a business logic component tier, including at least one business logic component code 
loaded by said presentation host on said user-mterface program, said business logic component 
code defining the interrelationships between objects rq)resented in said user interface; 

a data access abstraction layer tier, inchiding a data access abstraction layer code that 
allows business components code to read and write information to/firom a computing resource; 
and 

communicating with a remote computing resource through use of said data access 
abstraction layer code. 

116. A method as defined in claim 115, wherein said communicating step includes 
the step of communicating over the Internet. 

117. A method as defined in claim 115, wherein said communicating step con^rises 
the step of communicating with a remote data access tier in said computing resource, wherein 
said remote data access tier is a different tier from a data tier in said remote computing 
resource. 
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118* A metbod as defined m claim 116, wherein said comniunicatiiig step comprises 
the step of communicatiiig with a remote data access ti^ in said conq)uting resource, wherein 
said remote data access tier is a different tier from a data tier in said remote computing 
resource. 

1 19. A computer program product conq)rising: 

a medium with machine-readable code stored thereon which gives the ability to its 
computer to perform form creation tasks, comprising: 
first code for facilitating a schema database; 

second code for facilitating a template database separate from said schema database; 

third code for facilitating at least one linkage file, each containing code to link a 
selected schema in said schema database with a selected template in said template database; 

fourth code for facilitating a database of validation patterns separate from said schema 
database and said template database; and 

fifth code for facilitating a database of query information sqparate from said schema 
database and said template database. 

120. A conotputer program product as defined in claim 119, further comprising: 
a selector file database containing a plurality of selector files; 

an Actionset database containing a plurality of Actionsets; 

one or more eAgent specific action document databases containing eAgent specific 
action documents; 

at least one module for creation and manipulation of said databases. 

121. A conq)uter program product as defined in claim 119, furth^ comprising code 
for a plurality of different forms creation modules, with each of said modules providing a 
different method of manipulating one or more of said databases; and a forms designer 
configuration database listing which of said modules that are to be downloaded to different 
forms designers at runtime. 

122. A computer program product as defined in claim 119, wherein said code for 
said plurality of modules includes: 

code for a forms creation modules for allowing a forms designer to create a schema 
with validation, and to select regular expressions from said regular expression database for use 
in said validation. 
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123. A computer program product as defined in claim 122, wherein said code for 
said forms creation modules includes code to provide a link in said schema to said selected 
regular eTcpression in said regular expression database. 

124. A computei program product as defined in claim 121, wherein said code for 
said plurality of modules includes: 

code for a forms creaticHi module for allowing a foixos designer to select queiy 
information from said qaery information database to create elements in said schema. 

125. A computer program product as defined in claim 122, wherein said code for 
said forms creation module includes code to provide a link in a schema to said selected query 
information in said query database. 

126. A computer program product as defined in claim 121, wherein said code for 
said plurality of modules includes a regular e}q)ressions module for allowing said forms 
designer to add/change regular expressions in said regular expressions database. 

127. A computer program product as defined in claim 121, wherein said code for 
said plurality of modules includes a query mformation module for allowing said forms designer 
to add/change query information in said query information database. 

128. A computer program product as defined ia claim 119, further comprising code 
for facilitating an elements database for storing a plurality of different elements that may be 
reused in forms. 

129. A conq)uter program product as defined in claim 119, further comprising code 
for facilitating an actions module for including code for controllii^ at least one eAgent. 

130. A computer program product as defined in claim 121, further coxxxprising code 
for fecilitating a custom module for creation of user-defined controls. 
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